SSL certificate renewals can be messy.

The PEM files won’t work, Nginx cannot find the cert, and the green light won’t turn on no matter what you do.

You are not alone.

Hundreds of Nginx owners face SSL certificate renewal issues everyday, and here at Bobcares, our Support Engineers help them fix it in a jiffy.

We provide 100% transparent end-customer support to web hosts, digital marketers and VPS hosting providers.  Their customers raise tech support requests in their help desk, and our experts resolve it for them.

A lot of these customers use Nginx as their web server, and SSL cert renewal is a common issue we troubleshoot.

Today we’ll look at the top 5 issues reported by Nginx users, and how we resolve them:

1. Let’s Encrypt renewal command breaks

Many Nginx server owners these days use Let’s Encrypt as their certificate provider.

LetsEncrypt provides a way to renew SSL certificates using various command line tools, such as CertBot.

We’ve seen these reasons for CertBot based renewal to fail:

– Wrong WebRoot specified in renew command

CertBot uses a command line options called “WebRoot” to know where it should store the new certificates.

In newly migrated websites, or those that were updated recently, we’ve seen this setting to be wrong, causing the renewal to fail.

We adjust the CertBot settings to match the current website configuration to fix this error.

– “.well-known” folder deleted or wrong permissions set

CertBot uses a folder called “.well-known” in the website document root to check the authenticity of a request.

In many websites we’ve seen this folder with wrong permissions or missing altogether (possibly due to a security cleanup or a migration error). Restoring this folder quickly resolve this issue.

– HTTP authorization set for .well-known folder

Some sites setup an additional layer of security by protecting “.well-known” folder with .htaccess authentication.

This will break the command line based renewal process. So, in these sites, we disable HTTP authentication until the renewal is complete.

Of course, there are other errors as well related to CertBot based renewal.

That is because the renewal process goes through a complex sequence of steps, which includes auto-generating a CSR, contacting the LE servers using ACME protocol, passing the auth test using .well-known folder, setting up the certificates in the right folder, and successfully restarting the Nginx servers.

If any step in this sequence fails for some reason, the renewal fails.

So, there isn’t a real one-size-fit-all-solution. Instead, our Support Engineers gather evidence from the LetsEncrypt log file (/var/log/letsencrypt/letsencrypt.log), and systematically rule out each possibility to zero in on the root cause.

2. Old SSL shows up even after an update

Sure, SSL renewals can be tricky, but the most confusing of all is when after a successful renewal, the browser still shows the old expired SSL.

You’d think Nginx is doing that out of spite. But no, there are perfectly logical reasons for that.

Here are a few common causes:

– Cert uploaded to the wrong location

We’ve seen many cases where customers use old or incompatible renewal steps to upload new certificates.

It usually happens after a recent app upgrade, site migration or server upgrade.

In these cases the new certificates get stored in a folder that’s not Nginx’s certificate path.

To resolve this error, we look at the Nginx configuration files for the cert path, and then check if the new files are uploaded to this location.

– New certificate not uploaded in gateway server

In some web configurations, the Nginx server sits behind a load-balancer or a caching server.

So, it is not enough to upload the new certificate in the Nginx server. It should be uploaded to the front end servers as well.

Many site owners miss this step, leading to renewal errors.

– Nginx reload failed

There are times when Nginx won’t completely restart. The old process still keeps serving the old certificate from memory.

If we suspect a runaway Nginx process, we force kill it, and restart the service to fix this issue.

3. Intermediate certificates are built wrong or are corrupted

A pet peeve of Nginx users is Nginx’s inability to recognize intermediate certificates (aka cert bundles, aka certificate chain).

Instead, users are required to put their site certificate and all intermediate certificates into one file in the right order, and then point it to the “ssl_certificate” configuration option.

Yeah, it sounds complicated, and it sure is complicated for someone not used to tinkering with server backend.

That is why many webmasters see the error “Site Not Trusted” even after an apparently successful upgrade.

Almost all of these errors are caused by incorrect copy-paste of certificate data into the files. Some characters would be missing, or the certs will be pasted one on top of another.

All that cause cause the cert file to be corrupted, and connecting browsers will be unable to complete a successful verification.

We fix this by programmatically merging the Site Cert and Chain Cert so that there are not manual errors.

4. Forbidden errors while running cert renew

These days one cannot be too paranoid.

That is why some server administration panels like Plesk provide a way to block all access to hidden directories (ones that start with a period [ . ] ).

It is a measure to protect sensitive information some apps store in hidden directories.

Unfortunately, automatic cert installers such as Let’s Encrypt’s CertBot use hidden folders (/path/to/docroot/.well-known) for user validation.

Such validation measures will fail if hidden folder protection is enabled.

So, when we see a “403 Forbidden” error message in the cert renewal log files, we look for such security restrictions, and remove it until the new certificate is installed.

5. Nginx crashes (does not start) after certificate renewal

The most urgent issues often relate to crashed Nginx servers after a failed upgrade.

Some auto-installers are capable of changing configuration entries, but if the installer fails for some reason, it will break the Nginx configuration file.

In such cases, we restore the Nginx configuration file from backup to quickly get the site back online.

If a backup isn’t available, we get the site online by resetting the SSL configuration section that most automated tools target.

Once the site is back online, we make the changes manually to bring the new certificate online.

Conclusion

Certificate renewals can be a hassle. Today we’ve seen the top 5 issues that are reported by Nginx users while renewing SSL, and how our Support Engineers fix them.