Let's Encrypt Authority X3 not listed in Firefox 47 = WSS fails

It seems that after our last renewal of certificates using the command “./letsencrypt-auto renew” on certs that were about to expire, we have SOME Firefox 47 clients that can no longer use our WebRTC servers over WSS.

Client Environment #1:

  • Windows 7
  • Firefox 47.0
  • Chrome 51.0.2704.103 m

Client Environment #2:

  • Windows 8
  • Firefox 47.0
  • Chrome 51.0.2704.103 m

Server Environment:

  • CentOS 6.7
  • Apache 2.2.15
  • Doubango WebRTC2SIP 2.7

The same certificates issued by Let’s Encrypt work fine from ALL clients, and all environments when communicating to the server in these fashions:

  • Chrome over HTTPS
  • Chrome over WS (non-secure)
  • Chrome over WSS
  • Firefox over HTTPS
  • Firefox over WS (non-secure)

AND… in Client Environment #2 ONLY:

  • Firefox over WSS

SO… the only scenario where we get FAILURE (which we have not had in the past) is in Client Environment #1 with Firefox over WSS.

Consistently, we receive the message ONLY from Client Environment #1:

Firefox can’t establish a connection to the server at wss://website.com:10062

We do not think it is a Doubango WebRTC2SIP issue, since it works everywhere else, and as there is only 1 place to configure the SSL in its config.xml:


As well all Apache HTTPS sites for fine from all environments.

In Chrome, where everything also works fine over all protocols, we can see these “Intermediate Certification Authorities” for all client environments under “Settings” > “HTTPS/SSL” > “Manage Certificates”:

ONLY in Client Environment #2, do we the following under “Options” > “Advance” > “View Certificates”:

HOWEVER in Client Environment #1, we ONLY see the following “Certificate Authorities”:


  • Client Environment #2 seems to work fine over WSS with the “Let’s Encrypt Authority X3” installed.
  • Client Environment #1 does NOT work over WSS with only “Let’s Encrypt Authority X1” installed.


  1. Why does the “Let’s Encrypt Authority X1” certificate authority still work in Chrome (without the need of the additional “Let’s Encrypt Authority X3”) ?

  2. Why does the “Let’s Encrypt Authority X1” no longer work in Firefox?

  3. How do end-users add “Let’s Encrypt Authority X3” easily to their Firefox environment?

  4. Moving forward, will we have to force all browser clients to use “Let’s Encrypt Authority X3” certificate authority in the future?

Thank you so much for any insight you can provide!

Sorry about the length of this post. I’m also trying to help the WebRTC community by being as descriptive as possible

The way the CA system works is basically like this:

  • Your browser has a list of trusted root certificates
  • CAs use this root certificate to sign intermediate certificates
  • Using one of these intermediate certificates, CAs sign the actual certificate for your site

“Let’s Encrypt Authority X1” and “Let’s Encrypt Authority X3” are two examples of such intermediates. They are signed by a root certificate that is trusted by browsers. To put it simply: the intermediate certificate contain cryptographic proof that the owner of the trusted root certificate has signed it.

The certificates for your site are signed by this intermediate certificate. When a browser sees your certificate, it tries to find a path that leads up to a trusted root certificate (again using the cryptographic proof included in the certificate). In order to find a path to the trusted root certificate, the browser also needs the intermediate certificate. This is something the server can provide, and server software typically allows you to specify either a separate file that contains the intermediate certificate (certbot calls this file chain.pem) or the server expects one file that contains both your site’s certificate plus the intermediate certificate (fullchain.pem with certbot). Based on the configuration snippet you provided, it looks like you’re currently only using privkey.pem and cert.pem, so you’ll need to use either fullchain.pem instead of cert.pem, or provide chain.pem as a separate parameter (this should be covered in the documentation. The intermediate certificate might be called something like “CA certificate”).

You might wonder why it’s still working with some clients, and the answer is basically caching. When you visit a site that uses the “Let’s Encrypt Authority X3” certificate, some browsers cache this certificate for future usage, so any other site that uses the same intermediate certificate will work even when it doesn’t send along the intermediate.

1 Like

Short answer : test your wss server with ssllabs.com (yes you can if it’s on port 443). If it says “chain incomplete”, you must fix your configuration to provide the correct certificate chain.

1 Like

To add to pfg’s explanation, as well as caching, Microsoft’s browsers (Internet Explorer or Edge) can under some circumstances just fetch an intermediate certificate that seems relevant using the AIA URL baked into the certificate that was sent. You shouldn’t rely on this though because other browsers don’t do it; because clients might not successfully reach the URL with the intermediate certificate on; and because it represents another privacy hole for users where they access your site but then their browser has to contact another site about that…

I strongly recommend this simple site for testing for missing intermediate certificates:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.