Restore pem files

[trudger]

I wrongly delete all files in /etc/letsencrypt . When I try to get new one, I got an error message:

There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for exact set of domains

Is there a way I can find the four pem files back in the live directory? Thanks

[Osiris]

All the certificates issued by Let’s Encrypt are logged to Certificate Transparency logs, so you can find them at sites like http://crt.sh

But without the private key corresponding to the certificate, such a certificate is useless. And those private keys are also stored in /etc/letsencrypt.

So unfortunately you’ll have to wait for the rate limit to subside.

Question though: are you experimenting with Let’s Encrypt? Seems to me there’s quite a chance you are. If so, I’d strongly suggest to use the staging environment!

[trudger]

Thanks for your help.

I have four folders in /etc/letsencrypt: accounts, csr, keys and renewal. And, there are files in it. I believe I didn’t touch these folders. Do they help?

[Osiris]

You said you deleted all files in /etc/letsencrypt…

To restore the symlinks in the /etc/letsencrypt/live/ directory, you can try to run certbot update_symlinks. Perhaps it will make the /live/ directory itself if it’s missing, maybe not.

[trudger]

My bad, I think I deleted live and archive folders from /etc/letsencrypt but I’m not very sure. Anyway, I tried certbot-auto update_symlinks but nothing changed. It writes a log file though:

2017-03-18 14:49:34,887:DEBUG:certbot.main:Root logging level set at 20
2017-03-18 14:49:34,888:INFO:certbot.main:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2017-03-18 14:49:34,889:DEBUG:certbot.main:certbot version: 0.12.0
2017-03-18 14:49:34,889:DEBUG:certbot.main:Arguments: []
2017-03-18 14:49:34,890:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#standalone,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#webroot,PluginEntryPoint#apache,PluginEntryPoint#null)

[Osiris]

Well, if you still have the /keys/ directory, you might be in luck!

In /keys/ you can find the private key, probably the most recent one is the correct one. On https://crt.sh you can find your certificate.

You’d need to check if those files are corresponding to each other:

• openssl rsa -noout -modulus -in 00xx_key-certbot.pem | openssl sha256
• openssl x509 -noout -modulus -in downloaded_certificate_from_crt.sh.pem | openssl sha256

These two hashes should be the same.

With those two, you can ‘rebuild’ your /archive/example.com and /live/example.com where example.com is the name of your site/hostname (certbot defaults to the first hostname in the certificate):

• The 00xx_key-certbot.pem from /keys/ would become /archive/example.com/privkey1.pem
• The certificate you downloaded from crt.sh would become /archive/example.com/cert1.pem

Furthermore, you’ll need to download the “Let’s Encrypt Authority X3 (IdenTrust cross-signed)” from the Let’s Encrypt certificates page and put it in the folder like this: /archive/example.com/chain1.pem

After that, you’ll need to concatenate cert1.pem and chain1.pem to fullchain1.pem like this:

cat cert1.pem chain1.pem > fullchain1.pem

And then you might try certbot update_symlinks again or symlink all the files yourself.

[trudger]

I have two pem files in key directory and they have same sha256 so I copied one of them to /etc/letsencrypt/archive/<mydomain.com>/privkey.pem

I downloaded the crt file from crt.sh and converted it to cert.pem and verified it by the second command you provided and the value matches.

Then, I download the chain.pem via https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem and followed the command to get fullchain.pem

Everything looks ok but Nginx said key values mismatch:

nginx: [emerg] SSL_CTX_use_PrivateKey_file("/ssl/privkey.pem") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)

Anything I did wrong?

[Osiris]

The error message says it’s using the private key from the file /ssl/privkey.pem? Let’s Encrypt doesn’t use those paths… Did you put both the files somewhere else? I.e., is nginx using the correct files?

[trudger]

I use Nginx in a Docker image and it’s a mapped path. It actually already works. I just want to repeat the test and make sure I control it well so I deleted these files to “reset”. Then, I have the problem…

[Osiris]

Well…

If the results of openssl x509 -noout -modulus -in certificate_used_in_nginx.pem | openssl sha256 and openssl rsa -noout -modulus -in private_key_used_in_nginx.pem | openssl sha256 really give exactly the same result, I’m not sure why it won’t work…

By the way, I managed to switch rsa and x509 in my previous post above… Whoops, mea culpa… x509 is used for the certificate and rsa for the private key.

[trudger]

With new commands, nothing matches.

Keys directory:
openssl rsa -noout -modulus -in 0000_key-certbot.pem | openssl sha256
(stdin)= cf64613880b64a8c07f862007c94a259bc2378bf26281af878f27181b2e7fe67

openssl rsa -noout -modulus -in 0001_key-certbot.pem | openssl sha256
(stdin)= 6dcba9368c02c548fe0dabcaa99a5ccbb02abc7c718235a2f97419b7d018281a

All crt files downloaded:
openssl x509 -noout -modulus -in 105668699.crt | openssl sha256
(stdin)= 22733a3131bbe0eef75f3f2fe1a517d99fcfc94a0c07aa1b55e4a935da932425

openssl x509 -noout -modulus -in 105668021.crt | openssl sha256
(stdin)= 2fcb73770e3d938b61fc72e40849e1aef78fa9c3e4be7da817e25df3ce207f8c

openssl x509 -noout -modulus -in 105667418.crt | openssl sha256
(stdin)= 5bb9ab532eab8b96fe9e5b72bfce453c474a7c9121c4b32bcc2ff33112328b04

openssl x509 -noout -modulus -in 105666662.crt | openssl sha256
(stdin)= 55046ef741bb5dc18cbf6a6d66771a093555ea4cf7fe227f11199873b1d43833

openssl x509 -noout -modulus -in 105665871.crt | openssl sha256
(stdin)= fd9ebde23ef66ffd6168362dba4993a869d31edf4fef54ae23d04ac315d336f6

openssl x509 -noout -modulus -in 105580799.crt | openssl sha256
(stdin)= e6db0b242e969bea0cf35c2c1cde234a313829f5a4096ed0ed12b6045ebbda04

[Osiris]

Strange… I’m guessing you’d have to wait for a few more days until the rate limit of 7 days is lifted I’m afraid…

[trudger]

Seems it’s the only option for me… I appreciate your help anyway.

Last time I tried to request the certificate, instead of updating existing pem files, I got -0001, -0002…etc in the live and archive folders. Can I make everything works like first time? Like a “reset”?

[Osiris]

If /live/ and /archive/ are empty, you’d start from scratch.

[trudger]

Thank you!

–staging option seems still works so I’m using it for test purpose now and let’s see how it works after a week.

[Osiris]

The staging environment doesn’t have such strict rate limits indeed, ideal for testing (This is b/c the staging environment doesn’t allocate load on the Hardware Security Modules, which are used for the live environment and these HSM’s are or can be, as far as I have understood, quite a bottle neck for scalability.)

[trudger]

I hope I know it earlier. But anyway, I guess everything should be ok very soon. Very appreciate your help!