Recently, we set up a LetsEncrypt certificate for our website. It’s working perfectly aside from one (pretty big) issue: whenever we try to access the website in Firefox, it gives a security error, stating that the connection is not secure. It works fine in Chrome, Edge and Internet Explorer, so I assume this is exclusive to Firefox.
We are using Docker to run multiple web applications on the same server.
Our entrypoint on port 80 and 443 is a container running nginx.
This nginx server accepts HTTPS requests and the container’s filesystem has the certificate files for nginx.
The requests are then reverse-proxy routed either to a container running an Apache server with our homepage and a PhpBB forum on it or to a container with Tomcat Server running a Java Online Game Database API.
Both the Apache and Tomcat containers are in turn connected to a container running MySQL, each owning a database on the MySQL server.
We have two volumes: One data-volume holding our MySQL database files, and one holding our web-root that’s accessed by Apache.
Deploying web-content is done by dropping it into said web-root volume.
Our problem is now that the webserver that handles the certificates is distinct from the one serving the web files, and has no access to the web-root (since it’s only the reverse proxy of this system).
This is difficult to debug without looking at the domain in question. What specific error does Firefox show (under Technical Details)?
There are two other supported methods of verification.
There is tls-sni-01, which works by creating a virtual host on your server only accessible by TLS Server Name Indication with a special untrusted certificate. Let's Encrypt connects to the IP address associated with your domain, requests this virtual host via SNI, and then verifies that the certificate matches what they expect. This method is well supported by certbot, though the nginx support is considered beta quality.
There is also dns-01 verification, which doesn't require a web server at all, just that you be able to place a TXT record in your DNS. While Certbot does support this method, it has limited support for various DNS APIs; the dehydrated and acme.sh clients have support for a wider variety of DNS providers.
You could also achieve http-01 webroot validation in your configuration by redirecting paths beginning with /.well-known from your containerized domains to a common (sub)domain that does have a webroot on your frontend nginx server.
I find this a bit hard to comprehend...
If you control the entire "system", then I see two places to address the authentication:
NGINX
Apache
Either can accept and direct /.well-known/acme-challenge requests to:
local folder
remote folder
proxy requests to any other internal system (and on any port)
The system maintaining the certs could run the cert renewal job and receive/handle all the auth requests.
With something like:
location /.well-known {
root /local/folder/path;
allow all
}
Thank you both very much for your responses.
We don’t have a lot of experience with letsencrypt, so please bear with us.
Right, sorry for keeping the Firefox error so vague. Here’s a screenshot (the URL is censored because it’s private at the moment, but it shouldn’t matter from what I can see): http://i.imgur.com/xv7xQcN.png
The message on the bottom is in Dutch (I couldn’t find a way to make it appear in English even after changing Firefox’s language) but here’s a rough translation:
“The certificate is not trusted because the issuer certificate is unknown.
The server possibly does not send the correct intermediate certificates
Possibly, an extra root certificate needs to be imported
Error code: SEC_ERROR_UNKNOWN_ISSUER”
The strange thing is that some people don’t get this security warning while others do. It doesn’t seem to be related to the Firefox version either.
@rg305 The Apache server doesn’t need to have authentication or certificates, it runs entirely on HTTP because it never directly interacts with the internet.
It’s only linked to by the nginx container, which takes HTTPS requests from the internet and forwards them to the Apache server with HTTP.
If we want to do the authentication with the “.well-known” directory, is there an instruction document on how to do this?
We can configure the nginx server at container build time to include this location, but how do we use it to generate letsencrypt certificates?
Thank you very much for your answers, and we hope this problem can be solved!
This suggests that you are failing to serve the intermediate certificate, which is required for validity of your certificate chain. Some browsers are able to ignore this problem if they already know about the intermediate certificate from having visited another site that uses it.
I don’t know what client you’re using, but for example if you’re using Certbot, you need to serve fullchain.pem, not cert.pem.
You can also diagnose this problem with the tester at https://www.ssllabs.com/ssltest/ (if you want, you can disable posting the results publicly).
And after that just make sure it runs certbot renew daily via cron or ansible or whatever.
If you rebuild your container more than 5 times per week, you will need to persist /etc/letsencrypt and only issue once instead of when starting the container due to rate limits. If you only do it a few times per month or less, you might prefer keep it stateless.
Thank you very much for your replies! What Patches described sounds like the solution we were looking for. We’ll try to implement it as soon as we can, thanks again!
