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
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!
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?
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.
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)
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:
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):
/keys/ would become /archive/example.com/privkey1.pem
/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.
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?
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?
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…
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.
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
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…
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”?
If /live/ and /archive/ are empty, you’d start from scratch.
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.
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.)
I hope I know it earlier. 
But anyway, I guess everything should be ok very soon. Very appreciate your help!