Renewal on Cert

Help
1

It produced this output:

My cron job did not run because we have recently configured the server to be behind cloudflare. When I forced a renewal today the browser still says the cert is out of date. I shut down then started the entire server still to no avail.

When I checked my cert files this is what I found:
-rw-r–r-- 1 root root 6045 Sep 20 20:36 XXX.ca.
-rw-rw-r-- 1 ubuntu ubuntu 1956 Jan 7 17:27 XXX.ca.cer
-rw-rw-r-- 1 ubuntu ubuntu 623 Jan 7 17:27 XXX.ca.conf
-rw-rw-r-- 1 ubuntu ubuntu 1021 Jan 7 17:24 XXX.ca.csr
-rw-rw-r-- 1 ubuntu ubuntu 242 Jan 7 17:24 XXX.ca.csr.conf
-rw-rw-r-- 1 ubuntu ubuntu 1679 Sep 20 11:49 XXX.ca.key
-rw-r–r-- 1 root root 6045 Sep 20 20:43 XXX-full.ca.cer
-rw-rw-r-- 1 ubuntu ubuntu 3603 Jan 7 17:27 fullchain.cer

I believe my issue is the XXX-full.ca.cer and the XXX.ca.key did not update for whatever reason. Can somebody confirm or deny my thought and how to fix the issue.

My web server is (include version):
Ubuntu 16.04 NGINX 1.14.0

My hosting provider, if applicable, is: AWS

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No

2

You deleted a very importance piece in this puzzle:
I ran this command:

3

acme.sh --renew --dns dns_cf -d xxx.ca -d www.xxx.ca

There were no errors and stated that it copied the certs and the key.

4

Then you have the cert and the key.
acme.sh generates 7 files per issued cert (folder).
You show 8 files…
3 of which are dated Sep 20 (2 of which are owned differently - by root root).

I’m not sure what the other (extra) files are for, nor how they were created (presumably some extra step taken to merge some of the files).

But you should have the public cert as:
XXX.ca.cer
or
fullchain.cer (with cert and intermediate)

and the matching private key as:
XXX.ca.key

5

Can you show which files are being used by your web service?

I can’t even guess how the file (sized 6045) was created.
3603+1956=5559 (486 short)
3603+1679=5282 (763 short)
3603+1956+1679=7238 (1193 over)

6

Cloudflare generates its own certificates which your browser should see if you navigate to the site as an ordinary user would—and putting a server behind Cloudflare might stop Let's Encrypt certificate renewal from succeeding in some circumstances, but shouldn't stop your cron job from running. It would be great to see much more information about your configuration and the exact errors that you're getting.

7

After doing some reading cloudflare filters traffic and the dns_cf before was dns_gd and the cron job failed because of the redirect returned through the Go Daddy DNS servers which creates an issue. Godaddy handles the domain name where the DNS is redirected through cloudflare.

The domain has a wildcard registration so that might explain the 8th file. Going to have to check that root and ubuntu have permissions on the folder.

8

If you can get a specific error message from a specific Let’s Encrypt client application (like the acme.sh command that was called via cron or something), we might be able to help you out more easily! (especially if we could see the actual domain name and/or the actual browser error)

I agree that changing your DNS settings here could have an effect on your ability to renew, but it’s hard for us to confirm with certainty whether that’s the case unless we can see the specific errors that arise.

9

That is the issue there are no errors other than an expired cert message when the page is visited. I have poured over the log files and there are no errors with the manual renewal. Everything appeared to update properly and the only thing that I can see is that the key was not updated in the renewal. And that can only be seen when I checked the attributes of all files in the directory.

10

Are you sure that your web server configuration is pointed at those files as opposed to copies of them elsewhere on your system? Is it possible that you created the XXX-full.ca.cer file yourself back in September and have used that one, instead of one of the updated files, in your web server configuration?

(This is what I might guess from the file modification dates and the symptoms.)

11

Not my first rodeo. My nginx config is 100% configured properly.

    ssl_certificate             /home/ubuntu/.acme.sh/xxx.ca/fullchain.cer;
    ssl_certificate_key         /home/ubuntu/.acme.sh/xxx.ca/xxx.ca.key;
    ssl_trusted_certificate     /home/ubuntu/.acme.sh/xxx.ca/xxx.ca.cer;

Of those files referred to the only one that was not updated was the key and I suspect the issue is there. Might just have to perform an issue instead of a renew.

PS. for security reasons you should never divulge directory names in your when sharing your configurations.

12

If the key doesn’t match the certificate, the browser error in question should be different (or nginx should generate an error locally on the server!). It would be great to be able to see your actual domain name.

You could also run openssl x509 -text -noout -in /home/ubuntu/.acme.sh/xxx.ca/xxx.ca.cer to confirm that this is the certificate that you expect and openssl rsa -in /home/ubuntu/.acme.sh/xxx.ca/xxx.ca.key -pubout | openssl rsa -pubin -text -noout to confirm directly whether or not the key matches the subject key in the certificate.

13

Unless you're using OCSP staping, this is not necessarily the intended use of ssl_trusted_certificate, although I don't think it should harm anything.

1 Like
14

The confusion is the domain ends with .ca
So the ca.cer is NOT what would be expected as a CA.cer file.
But just a domain.cer file instead.

The file you should be using for that should be named (just):
ca.cer

15

Canadian domain. is dot ca

Problem solved after reading more. The renew command in acme.sh does not work with all configurations . Best to use the issue command instead.

Thanks for trying to help.

16

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