Hi there, I made the "update" of the certification roots on my ubuntu 16.04 hosting a BigBlueButton installation and, even if I fixed the "wget https://myserverbbb.example.com/default.pdf", I still have an "server error" problem when I try to start a room. BBB comes with a preinstalled procedure which assigns a Let's Encrypt certification automatically. I can renew the certificate manually and in the web page it appears to be valid but somewhere it is still not validated. I have 7 servers like this and I tested a lot of configuration changes: they works only if I change the certificate, using by example a different authority. Any clue? Thanks for your help.
Hi @dr.jkl welcome to hte LE community forum 
That depends on the ACME client in use and your control over it.
2 Likes
BBB is using certbot. I followed the instructions in the link you posted (Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2 - OpenSSL Blog) on how to avoid the check against the "bad" link in the chain ("mozilla/DST_Root_CA_X3.crt") launching the command "dpkg-reconfigure ca-certificates" and disabling the C.A., and that fixed only the "wget" part but not the whole system. I fixed the whole system only replacing the certificate with a new one issued by another C.A., probably, I suppose, because this new one is validated using a different chain path. But I found Let's Encrypt so usefull that I would like to go back to the original situation. Is there any log or config I can share to help you to help me? Thank again for your so quick respose.
1 Like
The renewal config file should be the place to make the necessary changes.
/etc/letsencrypt/renewal/EXAMPLE.COM.conf
On second thought...
The account number used may need to be changed and that isn't something that can be easily located and typed in.
So we are better off using certbot to get a cert form LE for you (so it can update all the details)
Let's start with the output of:
certbot certificates
/etc/letsencrypt/renewal/EXAMPLE.COM.conf
2 Likes
Here is the output, I changed my real domain with example.com:
Found the following certs:
Certificate Name: bbb.example.com
Domains: bbb.example.com
Expiry Date: 2022-01-03 06:58:59+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/bbb.example.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/bbb.example.com/privkey.pem
# renew_before_expiry = 30 days
version = 0.31.0
archive_dir = /etc/letsencrypt/archive/bbb.example.com
cert = /etc/letsencrypt/live/bbb.example.com/cert.pem
privkey = /etc/letsencrypt/live/bbb.example.com/privkey.pem
chain = /etc/letsencrypt/live/bbb.linfa.it/chain.pem
fullchain = /etc/letsencrypt/live/bbb.example.com/fullchain.pem
# Options used in the renewal process
[renewalparams]
account = 8399bc9e75e392366b64455a97608c5b
authenticator = webroot
server = https://acme-v02.api.letsencrypt.org/directory
B.T.W. BBB uses nginx as web engine.
1 Like
Well then that cert is valid and usable.
All you need to do, for now, is to update the web server to use it:
2 Likes
I know it is valid but it does work only in half 
I have already applied these .pem files to my configuration and I tested with the "wget" method. The wget downloads the correct file and validate the certifcate. The problem arises when I start a conference room: the system does not load any slide or gives me "server error" message. I do not understand why it works perfectly if I change the .pem files with something coming from another C.A. Am I the only one who is facing this problem with BBB and Let's Encrypt?
1 Like
I can't say specifically with BBB, but, in general, NO, you are NOT alone on this.
The main root expired and the new one is too new for older systems to even know about.
So there are two trust paths that LE offers - trying to serve both extremes.
But you have to make one choice (you can't serve both paths).
Door #1 gives all the newer devices the latest greatest but leaves the older devices out-of-service.
Door #2 gives the older devices a chance and should also work with the newer ones.
But there is a gray area where they are newish but fail when shown the older root.
So, if you must have both doors open, you will have to use another CA trust path (Door #3).
Have you tried both LE paths yet (or only the default one)?
2 Likes
I am sorry but I don't know the answer. Following your suggestions, I have disabled the "mozilla/DST_Root_CA_X3.crt" and restarted the server. How do I disable the "other door"?
1 Like
The quick test is to edit this file:
Do you know how to edit files on your server?
If so, tell me how you do it?
[there are many ways to edit files on servers and not all are compatible with the contents of that file]
2 Likes
Yes, I know how to edit a file in the server: I use nano. What should I change in the fullchain.pem file?
1 Like
Perfect!
Get in there and delete the last cert.
Certs are defined between the "BEGIN" and "END" lines.
[also delete those lines too - LOL]
-----BEGIN CERTIFICATE-----
BLAHBLAHBLAH
-----END CERTIFICATE-----
2 Likes
It works! Many thanks! I deleted the last certificate in the fullchain.pem file and restarted nginx. (What was the last certificate part for?)
Just for completion, I also found another way to solve the problem while I was following another thread onto the official BBB GitHub. I copy the solution here, it consists of replacing certbot with a different version that evidently is able to modify the chain:
sudo apt-get remove certbot
sudo apt-get install snapd
sudo snap install --classic certbot
sudo certbot renew --force-renewal --cert-name bbb.example.com --preferred-chain "ISRG Root X1"
sudo /etc/init.d/nginx restart
1 Like
That equals:
[only it does it immediately - which is a good test before making that change permanent via having to reissue the cert]
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.