NET::ERR_CERT_AUTHORITY_INVALID

[emailspeakcom]

Hi,

I have a v15.5 Beta 5 server installed on an AWS instance that has been working without issues since it was installed about a week ago. This morning I noticed that my phones behind an SBC were down, so I though this is an SBC issue, so I restarted the SBC. When that did not fix the issue, I noticed that my Android client was also down, and when I tried to login to the machine I got the NET::ERR_CERT_AUTHORITY_INVALID message from Chrome.

I tried calling the system, and it is still connected to the SIP trunk and picks up the phone to take a message, but the emails are not going out with the voicemail notification.

I rebooted the instance from the AWS console with the same results.

I went to an SSL Checker website (https://www.sslshopper.com/ssl-checker.html) and it reports that the certificate expired 29 days ago and that none of the common names in the certificate match the name that was entered in the website.

Since this is on AWS and I am using the pbsexpress with the 3CX certificate there is nothing that is configurable on my end - right?

Has anyone seen this before? Any help is greatly appreciated.

-Oze

 

[craigreilly]

havent had this issue - perhaps this:
https://www.3cx.com/community/threads/3cx-v15-5-8291-3-ssl-certificate-not-renew.54086/

 

[emailspeakcom]

Thanks for the reply. The weird part is that when I checked the SSL certificate for my URL, it shows that it had expired 29 days earlier, which seemed like the reason I was having the issue in the first place. And this is on a 3CX provided FQDN. Within an hour, the SBC reconnected and everything was back up and running. I checked the certificate again, and it shows that it does not expire for 85 more days! I restarted the SBC on the second site and there were no issues.

When the certificate was expired, both locations were down, as well the 6 android clients, and the none of my browsers would let me login to the console - but the server was still connected to the sip trunk and the digital receptionist was correctly handling the calls and forwarding all the voicemails to email as expected.

Not sure if this was some sort of certificate authority trust/propagation issue, but now everything works. Hopefully, this was just an isolated incident.

I appreciate the help - Thanks.

 

[YiannisH_3CX]

Hello @emailspeakcom

Glad to see the issue has now been resolved. Please keep an eye on the issue and report back if anything like this happens again.