Hello, when activating the domain and let’s encrypt to use SSL I get the following error in the CONSOLE:
[2025-01-09 14:52:59] ERROR[27988] pjproject: tlsc0x7f2530067f58 RFC 5922 (section 7.2) does not allow TLS wildcard certificates. Advise your SIP provider, please!
[2025-01-09 14:52:59] NOTICE[27988] res_pjsip/pjsip_transport_events.c: Transport '0.0.0.0-tls' to remote 'sbc-cn21-uc.ims.oi.net.br' - The server identity does not match to any identities specified in the certificate
and when making a call the following audio appears “the number is not responding”
If I read the messages correctly, the correct answer is to do as they say and ask the provider to use a compliant certificate. They are violating a MUST NOT condition, so they have no valid excuse.
Whilst the internet maxim “Be correct in what you send; be tolerant with what you receive” might normally apply, this is a security matter, so any toleration would have to subject to informed consent, which can be difficult to achieve in such cases, because people on forums wlll people to use the override option, and nine times out of ten they will do so without a thorough understanding of the implications.
The problem isn’t that it is self signed, but rather that it is not specific to one machine. Again not that this is not the certificate installed on Asterisk, but that on the peer. The message assumes that the peer is a provider, but I suppose that might not be the case.
Certificates exist for authentication, not for encryption. The only reason that they are needed for encryption is that, otherwise, anyone could cut into your line and set up an encrypted to both the true originator and true terminator, but have full access to the plain text.
Due to the growing usage of wildcard certificates, despite the specification, we added an option in Asterisk 20 and above that can be enabled to allow verification: res_pjsip - Asterisk Documentation
I’m not sure if this is exposed as an option in FreePBX.
You could offer any public key without its having been certified, in order to do the session key negotiation. Although the certificates carry the public key, there are, I believe, key negotiation protocols that don’t even require that. In any case, if someone overrides a certificate warning, as probably happens too often, they are then just using the certificate as a vehicle to contain the public key.
The purpose of the certificate is to confirm that it is your web site, and not a man in the middle. The people who issue it are a trusted third party. Most people also trust their browser/OS supplier to select trustworthy third parties, but you can always restrict the selection further, and I would suggest anyone in a high security environment should do so, and should probably exclude Lets Encrypt, because it has weak checks, based on DNS being trustworthy.
Although the main browsers probably exclude certifiers in countries considered hostile to the USA, if you are in another country, you should probably exclude ones in countries you consider unfriendly.
I haven’t looked closely recently, but the standard Microsoft set certainly used to include foreign certifiers with weak checks.
In the way people normally use browser, a proper certificate is only used for the public key of server, but both sides actually contribute to the key negotiation. Fully implemented, both sides would provide certificates, and you wouldn’t need to login.