Cert renewed, but date wrong

1

I installed a new certificate last January. Things went pretty smoothly, I think.

I recently received the notification that my certificate was about to expire. When I tried to renew it, it indicated the a new certificate was installed and would expire in 90 days. Just as I expected it.

My server a a Fedora 23 based system. I typed ./letsencrypt-auto certonly
It took me through various menus and finally said "congratulations, your new certificate will expire July 15, 2016.

However, when I use a “certificate testing site”, i.e. sslshopper.com, it tells me that my certificate expired 7 days ago, the scheduled expiration date for my original certificate. When I try to access the server via safari , it also tell me that my certificate has expired.

I looked for answers in the forum, but was unable to find any answers that seemed to apply.

I am somewhat new at this SSL so I would appreciate some help.

Thanks for your time.

imagemaster

2

Replacing existing certificates generally involves restarting your existing web server. It’s not clear to me if that’s part of your renewal procedure right now?

Most web servers support graceful restarts (e.g. apachectl graceful), so this would work without any downtime.

3

Thanks for your response.

On Fedora “service httpd restart” does the some thing, but the certificate still shows it as being expired.

I even tried “service httpd stop” followed by “service https start”. No joy

Your response did give me the idea to look for the “dates” of my cert files, i.e. cert1.pem, privkey1.pem, etc.

Unfortunately, all the dates were from Jan 8, 2016; when I created my original certificate. Their permissions were 0644 & the owner was root:root.

Not sure where to go from here.

imagmast

4

This sounds like you're pointing your apache to files in /etc/letsencrypt/archive/example.com/. That directory is basically an archive of all certificates and keys you've requested on that host. When you renew a certificate, a counter is increased and the new files are stored as cert2.pem, etc.

There's another directory, /etc/letsencrypt/live/example.com, which contains the same set of files, but those are actually just symlinks to the latest file in archive. The recommendation is to point the web server at those files instead.

5

Thanks for your response.

For some reason, I found the “new” cert files in /etc/letsencrypt/archive/{server name}.

not sure how they got there, but when I copied them to the directories listed in ssl.conf & restarted the server, all is well.

Thanks for you help & time.

imagemaster

6

...ánd you're going to get the same issues again in 90 days..

The official Let's Encrypt client updates the symbolic links in the /live/ directory, just like @pfg said, to the new certificates. You should really consider using those or symlink to them if you explicitely want to point your .conf to files in some other directory.

1 Like
7

Thanks for reminding me.

I was planning on documenting the locations, so that each time the cert is renewed, I’d know where to look for it.

Imagemaster

8

You should point Apache to /etc/letsencrypt/live instead of copying the files every time.

9

I had Apache2 look for the certs in /etc/letsencrypt/live/example.com which contains symlinks to /etc/letsencrypt/archive/example.com - the problem was that it pointed to for example fullchain1.pem and the renew-script created fullchain2.pem so in effect the cert was not renewed.

I’d say that’s a bug?

1 Like
10

That would definitely be a bug. If you still have the logs from that renewal, mind posting them for the client devs?

11

I think I have. I am not sure how informative they are. For example, at the end some lines like this are printed:

2016-04-14 19:25:01,895:DEBUG:letsencrypt.storage:Writing new private key to /etc/letsencrypt/archive/cv.martisak.se/privkey2.pem.

One thing that I am a bit confused by is that I have one directory called cv.martisak.se and another called cv.martisak.se-0001. The latter is referenced in the renewal config file. I guess I messed up somewhere at some point.

12

That’s probably because you added / removed domains without using the --expand flag?

13

@kelunik - Now a little bit bit off topic, but how do you mean? I have only one subdomain there, but there is also a totally different domain added later - I added that with a certonly command, just like the first. Didn’t know I was supposed to use the --expand flag?

14

That usually happens the inside live when you add or remove domains from a previously used set of domains, where each "set" is identified by the common name, so the first domain you listed in the certonly command, but where the rest of the domains is not equal to the set of domains when cv.martisak.se was created first.

So if you add or remove another domain without the --expand flag, a directory like cv.martisak.se-0001 will be created.

@schoen Why's that the default behavior instead of making the --expand option the default?

15

Removing is treated differently from adding. If you remove names, it’s always considered a new lineage. If you add certs, the client will by default prompt you interactively to ask which behavior you wanted.

16

@kelunik reading these posts, I realize I messed up my config last March by changing the way I automate the renewals. I now have a renewal-garbage/ directory that contains the old config files for my domains while the renewal/ directory only refers to my newest added domains. The live/ directory is a complete mess, the symlinks do not seem to have been updated in my latest attempts at renewing the certs. In the archive/ directory, the cert’s file indices do not always follow the chronology (cert1.pem dates from December, cert2.pem dates from June and cert3.pem dates from March).

Is there’s a way to clean this mess, like, manually updating the symlinks in live/ to point to the latest versions, ordering the cert file indices properly in archive/, and hope that the next renewal will catchup from there properly?

17

@thbb, that should work; note that the list of domains to include in the renewed cert will be based on the certificate referred to by the live/cert.pem link.