TLS SIP always giving 503 Certificate Validation Failure

[oJo]

We have set up a SIP Trunk with Secure SIP but it always returns 503 Certificate Validation Failure when attempting to register. This error is even given when the destination port is completely wrong. Is there any way to debug this more easily and find the actual problem?

 

[eddv123]

Wireshark from 3CX possibly: https://www.3cx.com/docs/capture-network-traffic/

The actual error you are seeing is a 5xx style response which denotes - The server is in maintenance or is temporarily overloaded and cannot process the request.

This is a server/provider side error so I would contact them about this.

 

[oJo]

The error is not generated by the provider, it occurs even if we send the registration query to an invalid port.

 

[eddv123]

but it always returns 503 Certificate Validation Failure when attempting to register.

The error is not generated by the provider, it occurs even if we send the registration query to an invalid port.

If you are sure about this then run a Wireshark capture as advised and lets see where that response is coming from - go to Telephony >> VoIP Calls >> Flow sequence to see this.

 

[JohnS_3CX]

When enabling TLS on a trunk, you need to also upload a valid PEM certificate (given to you from your provider). Can you confirm?

 

[oJo]

Yeah they gave me the appropriate letsencrypt root certificate.

 

[JohnS_3CX]

Which provider? Is this a 3CX supported provider or other?

The connection probably has not been tested for compatibility and you may need to make further changes. Providers usually have SRV records that point you to the right registrar IP based on what service you are trying to reach. This post may help you:
https://www.3cx.com/community/threads/503-certificate-validation-failure-outbound-calls.54273/

 

[oJo]

Which provider? Is this a 3CX supported provider or other?

The connection probably has not been tested for compatibility and you may need to make further changes. Providers usually have SRV records that point you to the right registrar IP based on what service you are trying to reach. This post may help you:
https://www.3cx.com/community/threads/503-certificate-validation-failure-outbound-calls.54273/

It's not a 3CX Partner, but we have unsecured trunks working flawlessly for a long time. The only problem is the one I listed before with 3CX always saying 503

 

[JohnS_3CX]

We cannot compare unsecured trunks in this case, those will work because you already meet their requirements. The requirement for TLS turnks is to have a valid PEM certificate (non-wildcard!) issued by the SIP provider so the PBX can talk to them using this certificate. You also have to insert a registrar that supports TLS (ie. don't try to authenticate on their non secured registrar - they have to give you the correct one). Their SRV records must also be able to resolve to a TLS based registrar and the port you use will also be different (ie. providers may use 5060 for UDP, and 5061 for TLS).

I think it is best you contact them to help you, as you probably have the wong configuration in the trunk now and they are rejecting you with a 503. Please confirm the above and let us know accordingly to see what can be done

You can search the forum also for "secure trunk". This post can also shed some light on common cert errors: https://www.3cx.com/community/threads/secure-sip-on-trunk-503-certificate-validation-failure.70611/

 

[oJo]

We cannot compare unsecured trunks in this case, those will work because you already meet their requirements. The requirement for TLS turnks is to have a valid PEM certificate (non-wildcard!) issued by the SIP provider so the PBX can talk to them using this certificate. You also have to insert a registrar that supports TLS (ie. don't try to authenticate on their non secured registrar - they have to give you the correct one). Their SRV records must also be able to resolve to a TLS based registrar and the port you use will also be different (ie. providers may use 5060 for UDP, and 5061 for TLS).

I think it is best you contact them to help you, as you probably have the wong configuration in the trunk now and they are rejecting you with a 503. Please confirm the above and let us know accordingly to see what can be done

You can search the forum also for "secure trunk". This post can also shed some light on common cert errors: https://www.3cx.com/community/threads/secure-sip-on-trunk-503-certificate-validation-failure.70611/

It is set up exactly as to the specifications of our provider, the error seems to be coming from the PBX.

 

[YiannisH_3CX]

Once you switch to TLS the PBX will try to establish a TCP connection and try to establish a TLS connection using the certificate you provided.
If the certificate is not correct or does not cover your registrar address then you will receive the error you are describing.
Can you tell us what registrar you are using to connect to the provider?

 

[JohnS_3CX]

Can you check the certificate they gave you please and see if it is a wildcard certificate?

For example:

Wildcard:
*.provider.com


Non Wildcard:
sip.provider.com

 

[oJo]

Can you check the certificate they gave you please and see if it is a wildcard certificate?

For example:

Wildcard:
*.provider.com
View attachment 15367

Non Wildcard:
sip.provider.com
View attachment 15366

They gave me the authoritative certificate, not their own, shouldn't that woprk as well? Using the letsencrypt cert itself wouldn't be very useful, as it changes all the time.

 

[JohnS_3CX]

That doesn't tell us much I'm afraid. Can you grab that certificate, rename it to *.crt and doubleclick it in Windows to see what it looks like? I would like to see it in this form:

 

[oJo]

 

[JohnS_3CX]

This file does not belong to the provider, it belongs to Let's Encrypt as a Root CA, hence the TLS handshake fails.

The provider must give your their own Let's Encrypt certificate that contains their own FQDN server name like the screenshot I showed you above with ours that says "www.3cx.com" in it.

Unless they give you the correct file, TLS SIP will not be possible unfortunately.

By the way, which provider are you using?