Too many certificates already issued for exact set of domains

Hello,

I have used successfully Let’s encrypt certificate since may 2017. I decide to automate every day the renewal of the certificate thanks to the crontab with this line :
sudo service nginx stop && sudo certbot renew --quiet --rsa-key-size 4096 && sudo service nginx start

Until the 3rd of july 2017, everything works like a charm :sunglasses:
After this date, Let’s Encrypt create each day a new certificate for my domain. Quickly I reach the maximum of 8 certificates for one domain and I obtain this error message at each automatical renewal : An unexpected error occurred: There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for exact set of domains: seafile.nolla.eu Please see the logfiles in /var/log/letsencrypt for more details.

Of course as a fool, I delete all my directories /etc/letsencrypt/live archive and renewal to try to delete all certificates and restart with a virgin situation. It appears that was a very bad idea and now I can’t regenerate a certificate with the classic command sudo certbot certonly.

My question is how I can delete the Let’s Encrypt certificates ?
@Let’s Encrypt Admin : Moreover, it appears that there is a bug in the current renewal process. Could you fix it ?

Hi @IssueFindings,

Sorry that you ran into trouble with Certbot.

I agree that Certbot should not have tried to renew the same certificate every day unless you added something like --force-renew, which it doesn’t appear that you did. Could you please post your logs from /var/log/letsencrypt showing the renewal events?

Also, what error message are you getting now when trying to obtain a new certificate with certbot certonly?

Hello,

Please find below the result of my log file.
2017-07-07 22:43:43,564:DEBUG:certbot.main:Root logging level set at 30 2017-07-07 22:43:43,567:INFO:certbot.main:Saving debug log to /var/log/letsencrypt/letsencrypt.log 2017-07-07 22:43:43,570:DEBUG:certbot.main:certbot version: 0.10.2 2017-07-07 22:43:43,570:DEBUG:certbot.main:Arguments: ['-q'] 2017-07-07 22:43:43,573:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#stant#standalone) 2017-07-07 22:43:43,576:DEBUG:certbot.renewal:no renewal failures

How can I do to maintain my automatic renewal with crontab ? What I need to change ?

With the command sudo certbot certonly --rsa-key-size 4096 --webroot -w /var/www/website -d website I obtain the error message below.
Saving debug log to /var/log/letsencrypt/letsencrypt.log Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org Obtaining a new certificate Performing the following challenges: http-01 challenge for website Using the webroot path /var/www/website for all unmatched domains. Waiting for verification... Cleaning up challenges Generating key (4096 bits): /etc/letsencrypt/keys/0018_key-certbot.pem Creating CSR: /etc/letsencrypt/csr/0018_csr-certbot.pem An unexpected error occurred: There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for exact set of domains: seafile.nolla.eu Please see the logfiles in /var/log/letsencrypt for more details.

Many thanks for your help. Have a nice day.

There should be other log files showing times when Certbot did attempt a renewal. What I don’t understand is why it did so, because the renewal logic is only supposed to attempt renewals when the certificate is near expiry.

Could you please also post the entire crontab line and any other crontab entries that you might have that relate to Certbot, and also the output of running certbot certificates?

Hello,

1) The result of the command sudo certbot certificates :
`Saving debug log to /var/log/letsencrypt/letsencrypt.log

No certs found.
-------------------------------------------------------------------------------`

Extract of /var/log/letsencrypt/letsencrypt.log :
2017-07-09 13:58:44,521:DEBUG:certbot.main:Root logging level set at 20 2017-07-09 13:58:44,525:INFO:certbot.main:Saving debug log to /var/log/letsencrypt/letsencrypt.log 2017-07-09 13:58:44,528:DEBUG:certbot.main:certbot version: 0.10.2 2017-07-09 13:58:44,528:DEBUG:certbot.main:Arguments: [] 2017-07-09 13:58:44,532:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone)

2) Extract of my crontab
0 0 * * * sudo apt-get update -y && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y && sudo rkhunter --update && sudo rkhunter --propupdate && tail /var/log/apt/history.log | mail -s "update done" xx@email.com 0 1 * * * sudo apt-get autoclean -y && sudo apt-get autoremove --purge -y && sudo reboot @reboot /home/pi/SeaFile/seafile-server-latest/seafile.sh start && /home/pi/SeaFile/seafile-server-latest/seahub.sh start-fastcgi && sudo service transmission-daemon restart @reboot sleep 15 && sudo service nginx stop && sudo certbot renew --quiet --rsa-key-size 4096 && sudo service nginx start && echo "Restart done" | mail -s "Restart done" xx@email.com @reboot sleep 30 && sudo clamscan -r /

3) Certificates renewal
Picture below shows you that my certificate has renewed the 3rd, 4th and 5th of July even if the initial certificate of 4th of may 2017 is still available.

Log file of the 4th of July 2017
`2017-07-04 23:01:20,105:DEBUG:certbot.main:Root logging level set at 30
2017-07-04 23:01:20,109:INFO:certbot.main:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2017-07-04 23:01:20,112:DEBUG:certbot.main:certbot version: 0.10.2
2017-07-04 23:01:20,113:DEBUG:certbot.main:Arguments: [’–quiet’, ‘–rsa-key-size’, ‘4096’]
2017-07-04 23:01:20,116:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone)
2017-07-04 23:01:20,158:DEBUG:parsedatetime:parse (top of loop): [30 days]
2017-07-04 23:01:20,193:DEBUG:parsedatetime:CRE_UNITS matched
2017-07-04 23:01:20,195:DEBUG:parsedatetime:parse (bottom) [30 days]
2017-07-04 23:01:20,195:DEBUG:parsedatetime:weekday False, dateStd False, dateStr False, time False, timeStr False, meridian False
2017-07-04 23:01:20,196:DEBUG:parsedatetime:dayStr False, modifier False, modifier2 False, units True, qunits False
2017-07-04 23:01:20,196:DEBUG:parsedatetime:_evalString(30 days, time.struct_time(tm_year=2017, tm_mon=7, tm_mday=4, tm_hour=23, tm_min=1, tm_sec=20, tm_wday=1, tm_yday=185, tm_isdst=0))
2017-07-04 23:01:20,196:DEBUG:parsedatetime:_buildTime: [30 ][days]
2017-07-04 23:01:20,197:DEBUG:parsedatetime:units days --> realunit days
2017-07-04 23:01:20,197:DEBUG:parsedatetime:return
2017-07-04 23:01:20,197:DEBUG:certbot.storage:Should renew, less than 30 days before certificate expiry 2017-08-02 21:05:00 UTC.
2017-07-04 23:01:20,198:INFO:certbot.renewal:Cert is due for renewal, auto-renewing…
2017-07-04 23:01:20,263:DEBUG:certbot.plugins.selection:Requested authenticator webroot and installer None
2017-07-04 23:01:20,280:DEBUG:certbot.plugins.selection:Single candidate plugin: * webroot
Description: Place files in webroot directory
Interfaces: IAuthenticator, IPlugin
Entry point: webroot = certbot.plugins.webroot:Authenticator
Initialized: <certbot.plugins.webroot.Authenticator object at 0x73d33eb0>
Prep: True
2017-07-04 23:01:20,284:DEBUG:certbot.plugins.selection:Selected authenticator <certbot.plugins.webroot.Authenticator object at 0x73d33eb0> and installer None
2017-07-04 23:01:20,646:DEBUG:certbot.main:Picked account: <Account(43e8f1849e626ccd31875ba86f8ecfa9)>
2017-07-04 23:01:20,655:DEBUG:root:Sending GET request to https://acme-v01.api.letsencrypt.org/directory.
2017-07-04 23:01:20,684:INFO:urllib3.connectionpool:Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2017-07-04 23:01:21,197:DEBUG:urllib3.connectionpool:“GET /directory HTTP/1.1” 200 352
2017-07-04 23:01:21,201:DEBUG:acme.client:Received response:
HTTP 200
content-length: 352
strict-transport-security: max-age=604800
boulder-request-id: 3X7FIWAsMMGY_3Qf9xVmfO-SACS92F3PK0mA2gJ1aZs
expires: Tue, 04 Jul 2017 23:01:21 GMT
server: nginx
connection: keep-alive
pragma: no-cache
cache-control: max-age=0, no-cache, no-store
date: Tue, 04 Jul 2017 23:01:21 GMT
x-frame-options: DENY
content-type: application/json
replay-nonce: sdsPJglzth14ZhJMomXC5Ou2ju02ErfkVpJCFw7BhbM

{
“key-change”: “https://acme-v01.api.letsencrypt.org/acme/key-change”,
“new-authz”: “https://acme-v01.api.letsencrypt.org/acme/new-authz”,
“new-cert”: “https://acme-v01.api.letsencrypt.org/acme/new-cert”,
“new-reg”: “https://acme-v01.api.letsencrypt.org/acme/new-reg”,
“revoke-cert”: “https://acme-v01.api.letsencrypt.org/acme/revoke-cert
}
2017-07-04 23:01:21,202:INFO:certbot.main:Renewing an existing certificate
2017-07-04 23:01:21,204:DEBUG:root:Requesting fresh nonce
2017-07-04 23:01:21,205:DEBUG:root:Sending HEAD request to https://acme-v01.api.letsencrypt.org/acme/new-authz.
2017-07-04 23:01:21,454:DEBUG:urllib3.connectionpool:“HEAD /acme/new-authz HTTP/1.1” 405 0
2017-07-04 23:01:21,457:DEBUG:acme.client:Received response:
HTTP 405
content-length: 91
allow: POST
boulder-request-id: usRsGi_LnsWvCWS_A71P4fKNZsPUUUKnJbmu34r9uQA
expires: Tue, 04 Jul 2017 23:01:21 GMT
server: nginx
connection: keep-alive
pragma: no-cache
cache-control: max-age=0, no-cache, no-store
date: Tue, 04 Jul 2017 23:01:21 GMT
content-type: application/problem+json
replay-nonce: EKtSuuO7fV6CORo3PVoTUlmD1sWpOCFPZtIu0vPB4Uc

2017-07-04 23:01:21,458:DEBUG:acme.client:Storing nonce: EKtSuuO7fV6CORo3PVoTUlmD1sWpOCFPZtIu0vPB4Uc
2017-07-04 23:01:21,462:DEBUG:acme.client:JWS payload:
{
“identifier”: {
“type”: “dns”,
“value”: “website”
},
“resource”: “new-authz”
}
2017-07-04 23:01:21,772:DEBUG:root:Sending POST request to https://acme-v01.api.letsencrypt.org/acme/new-authz:
{
“header”: {
“alg”: “RS256”,
“jwk”: {
“e”: “AQAB”,
“kty”: “RSA”,
“n”: “xx”
}
},
“protected”: “xx”,
“payload”: “xx”,
“signature”: “xx”
}
2017-07-04 23:01:22,034:DEBUG:urllib3.connectionpool:“POST /acme/new-authz HTTP/1.1” 201 1492
2017-07-04 23:01:22,037:DEBUG:acme.client:Received response:
HTTP 201
content-length: 1492
strict-transport-security: max-age=604800
boulder-request-id: smdaaY-2AbtRaBfhBM8qwO5MjfPY4KTELd-dM1AszF4
boulder-requester: 13915366
expires: Tue, 04 Jul 2017 23:01:22 GMT
server: nginx
connection: keep-alive
link: https://acme-v01.api.letsencrypt.org/acme/new-cert;rel=“next”
location: https://acme-v01.api.letsencrypt.org/acme/authz/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs
pragma: no-cache
cache-control: max-age=0, no-cache, no-store
date: Tue, 04 Jul 2017 23:01:22 GMT
x-frame-options: DENY
content-type: application/json
replay-nonce: M3I6rWkxgTeO7DVcw-eefXBfpBADYZZ6GMjSy7PApiQ

{
“identifier”: {
“type”: “dns”,
“value”: “website”
},
“status”: “valid”,
“expires”: “2017-08-02T22:38:52Z”,
“challenges”: [
{
“type”: “tls-sni-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs/1473950952”,
“token”: “SShGMca-4OatuyjQas9Abe_jfuQKUe5FoisFk9XYkJo”
},
{
“type”: “dns-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs/1473950953”,
“token”: “aW-ct37N_QDYSLJvo8Q5UjuQYXiomJPvo_AljVSwmwM”
},
{
“type”: “http-01”,
“status”: “valid”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs/1473950954”,
“token”: “xx”,
“keyAuthorization”: “xx”,
“validationRecord”: [
{
“url”: “http://website/.well-known/acme-challenge/uXc5lI3fX68nNgL4uQLp8hbhCGss0X7SGnULOf2fodg”,
“hostname”: “website”,
“port”: “80”,
“addressesResolved”: [
“xx.xx.xxx.xxx”
],
“addressUsed”: “xx.xx.xxx.xxx”,
“addressesTried”:
}
]
}
],
“combinations”: [
[
0
],
[
1
],
[
2
]
]
}
2017-07-04 23:01:22,038:DEBUG:acme.client:Storing nonce: M3I6rWkxgTeO7DVcw-eefXBfpBADYZZ6GMjSy7PApiQ
2017-07-04 23:01:22,042:INFO:certbot.auth_handler:Performing the following challenges:
2017-07-04 23:01:22,042:INFO:certbot.auth_handler:http-01 challenge for website
2017-07-04 23:01:22,043:DEBUG:certbot.plugins.webroot:Creating root challenges validation dir at /var/www/website/.well-known/acme-challenge
2017-07-04 23:01:22,118:DEBUG:certbot.plugins.webroot:Attempting to save validation to /var/www/website/.well-known/acme-challenge/uXc5lI3fX68nNgL4uQLp8hbhCGss0X7SGnULOf2fodg
2017-07-04 23:01:22,121:INFO:certbot.auth_handler:Waiting for verification…
2017-07-04 23:01:22,122:DEBUG:acme.client:JWS payload:
{
“keyAuthorization”: “uXc5lI3fX68nNgL4uQLp8hbhCGss0X7SGnULOf2fodg.ynbJkrKSfThtp7kFfgJrQ8HsYwJ8MaLRVcioJjTVVzU”,
“type”: “http-01”,
“resource”: “challenge”
}
2017-07-04 23:01:22,357:DEBUG:root:Sending POST request to https://acme-v01.api.letsencrypt.org/acme/challenge/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs/1473950954:
{
“header”: {
“alg”: “RS256”,
“jwk”: {
“e”: “AQAB”,
“kty”: “RSA”,
“n”: “xx”
}
},
“protected”: “xx”,
“payload”: “xx”,
“signature”: “xx”
}
2017-07-04 23:01:22,770:DEBUG:urllib3.connectionpool:“POST /acme/challenge/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs/1473950954 HTTP/1.1” 202 671
2017-07-04 23:01:22,773:DEBUG:acme.client:Received response:
HTTP 202
content-length: 671
boulder-request-id: cYepYBFF7j9HGhfegQaC_Z-8c8bS0EnM2lXB7iYPw-I
boulder-requester: 13915366
expires: Tue, 04 Jul 2017 23:01:22 GMT
server: nginx
connection: keep-alive
link: https://acme-v01.api.letsencrypt.org/acme/authz/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs;rel=“up”
location: https://acme-v01.api.letsencrypt.org/acme/challenge/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs/1473950954
pragma: no-cache
cache-control: max-age=0, no-cache, no-store
date: Tue, 04 Jul 2017 23:01:22 GMT
content-type: application/json
replay-nonce: WHOvA7ESfx9I7lLZm1R-p1SBZ-cBFY8mrrpXvKX80pQ

{
“type”: “http-01”,
“status”: “valid”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs/1473950954”,
“token”: “xx”,
“keyAuthorization”: “xx”,
“validationRecord”: [
{
“url”: “http://website/.well-known/acme-challenge/uXc5lI3fX68nNgL4uQLp8hbhCGss0X7SGnULOf2fodg”,
“hostname”: “website”,
“port”: “80”,
“addressesResolved”: [
“xx.xx.xxx.xxx”
],
“addressUsed”: “xx.xx.xxx.xxx”,
“addressesTried”:
}
]
}
2017-07-04 23:01:22,774:DEBUG:acme.client:Storing nonce: WHOvA7ESfx9I7lLZm1R-p1SBZ-cBFY8mrrpXvKX80pQ
2017-07-04 23:01:25,778:DEBUG:root:Sending GET request to https://acme-v01.api.letsencrypt.org/acme/authz/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs.
2017-07-04 23:01:26,051:DEBUG:urllib3.connectionpool:“GET /acme/authz/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs HTTP/1.1” 200 1492
2017-07-04 23:01:26,054:DEBUG:acme.client:Received response:
HTTP 200
content-length: 1492
strict-transport-security: max-age=604800
boulder-request-id: YuQP26b4zjdYBhBSvaRnr8AuH976a8oXIthFFRONGWQ
expires: Tue, 04 Jul 2017 23:01:26 GMT
server: nginx
connection: keep-alive
link: https://acme-v01.api.letsencrypt.org/acme/new-cert;rel=“next”
pragma: no-cache
cache-control: max-age=0, no-cache, no-store
date: Tue, 04 Jul 2017 23:01:26 GMT
x-frame-options: DENY
content-type: application/json
replay-nonce: 9SXbNlN40Qgs-jTZlGrIm4RPv9zS6s84dB5dThyjQys

{
“identifier”: {
“type”: “dns”,
“value”: “website”
},
“status”: “valid”,
“expires”: “2017-08-02T22:38:52Z”,
“challenges”: [
{
“type”: “tls-sni-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs/1473950952”,
“token”: “SShGMca-4OatuyjQas9Abe_jfuQKUe5FoisFk9XYkJo”
},
{
“type”: “dns-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs/1473950953”,
“token”: “aW-ct37N_QDYSLJvo8Q5UjuQYXiomJPvo_AljVSwmwM”
},
{
“type”: “http-01”,
“status”: “valid”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/tnDiMggXuRV_kHEJ8ITDRndLUqCafeyddb5dbTJ5NOs/1473950954”,
“token”: “xx”,
“keyAuthorization”: “xx”,
“validationRecord”: [
{
“url”: “http://website/.well-known/acme-challenge/uXc5lI3fX68nNgL4uQLp8hbhCGss0X7SGnULOf2fodg”,
“hostname”: “website”,
“port”: “80”,
“addressesResolved”: [
“xx.xx.xxx.xxx”
],
“addressUsed”: “xx.xx.xxx.xxx”,
“addressesTried”:
}
]
}
],
“combinations”: [
[
0
],
[
1
],
[
2
]
]
}
2017-07-04 23:01:26,056:INFO:certbot.auth_handler:Cleaning up challenges
2017-07-04 23:01:26,057:DEBUG:certbot.plugins.webroot:Removing /var/www/website/.well-known/acme-challenge/uXc5lI3fX68nNgL4uQLp8hbhCGss0X7SGnULOf2fodg
2017-07-04 23:01:26,058:DEBUG:certbot.plugins.webroot:All challenges cleaned up, removing /var/www/website/.well-known/acme-challenge
2017-07-04 23:01:57,340:INFO:certbot.crypto_util:Generating key (4096 bits): /etc/letsencrypt/keys/0007_key-certbot.pem
2017-07-04 23:02:00,585:INFO:certbot.crypto_util:Creating CSR: /etc/letsencrypt/csr/0007_csr-certbot.pem
2017-07-04 23:02:00,907:DEBUG:certbot.client:CSR: CSR(file=’/etc/letsencrypt/csr/0007_csr-certbot.pem’, data=‘0\x82\x04\x8e0\x82\x02v\x02\x01\x020\x1b1\x190\x17\x06\x03U\x04\x03\x0c\x10seafile.nolla.eu0\x82\x02"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x82\x02\x0f\x000\x82\x02\n\x02\x82\x02\x01\x00\x90q\t\xd5\xed\x92vL\x17s\x9ci\x05H\x91V(\xd7\x95\x02~\x14\xfeM~\xfa\xd0\x94\x8dc\x95\xa6{p?\x9a\x10\xbd\xc6\xda\x85\xab\xf7\x8e\xab\x15\xd0\x173$\x04zfL\xb3\x032\x83\x96~\xb5\xe0\xd6\xe1\xad\x0e?\xfa\x1a\xba\xf3\xc3\xe6\xe5\x1a\x01@\xf5]t\x1b\x80_+\x11p\x03|t"Q\xd3\x86\x17=\x05\xde\x05\xa6\x00\xdaUsq\xf7\xf4\x00\xd8\x9b\xb3\xcc,\x19\xeb\x0f+\xcc\x18\xa4[\x1e\x80D\xe6\xa98\xa91N\xf7\xf3\x92\xe4)\x0c\xd1\xd1p\xb4\x89\xa3\xc8\xc4S\xf5E\xca\xcf\x7f\xca\x91e\x11\xf8\x98\xca\xf0\x0e\x86\xfd\xed\xd4):I>\xb9\xa2\xac\x8c\x10\x1aN\xea0\x02>\x01#\xc3\x02Y\x84p\xa6\x18\x87\x10\xac\xadh\t\x7f\xaa\x04\xe8\xe9o)T\x01\r\x8c(\xb0\xfa\xc5\x92b,\x99nGsH\xdc\xb5’\xd1\xc3\x12{\xd6\x97T\xe6\xf6}\r\n\xe1\xf4 \xc8;\xba;s0Y}\xd4EJ\xe7\xacI\xfb\x95q~N[\x96.\x94\x84aa\xd5\xb8g3N\xe8\xd0\x97\xf9\xaa\xfa\xe0\x01\x81\xd4\xcc\xfc\xf1\x04\xb8|i>\x91\xe8\x03\xc3!\x8c\xe1\x823E\xf90 z\x9a\x14T\xbf+\x8a\x80\x8aGA\xa1\x00\x86\x92\xc85L\xe9\x14g\xde\xc0\xd8\x84\x99r\xbfJy\xab;Ps)\x9d\x03N\xab\x82\xae\xe1\x9a\xfb \xf10{\xe75!Q\x84\x7f\xab\xb3\xc6\x8b\xe7\xfc\x8f\xbdM\x02\xba\xad|\xd9d\x9cO\x8e8\xd1wu\x92^g0Q\x194\xd0\xdd\xfaxy\x98|\xe1.P\x1d\xf1\x11\xee\x14\xe6+\x01\xedB*5\xfd\x1br\xa0\xec|\xbf%\xd2\x8do\xd04\xf9yap\x1c\xe2Kp[\xba\xed\xa9&c\xee\x95\xb3\x1b\x943\x9c"e(\x86\xa42\xe9,a70\xc0s\xf2\x9a\x1aE\x00\xd1\x1b\xf3X\x8b8\xb0H\x84\x86\xeb\xaf\xb6)\x91]FC\x89^\x8e\x96\x93 \xaan\xe6\xce\xb3-*S"\x9d\xfc:\xbf\xba\xdfT\x0bo\xc2\xf2\xa8\x9ex\x1a9\x0b@\xdbx\x94\xb8\x03\x02\x03\x01\x00\x01\xa0.0,\x06\t*\x86H\x86\xf7\r\x01\t\x0e1\x1f0\x1d0\x1b\x06\x03U\x1d\x11\x04\x140\x12\x82\x10seafile.nolla.eu0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x0b\x05\x00\x03\x82\x02\x01\x00p\xd4\x97C[\xe3Ik1\xf6\xce\x02b,\x98"\xd0\xf6\xcf<\xad\xaf\xd7N\xb9*\x9f\xaa\xe7\x96W\x89\xb5\x94\xc5H\x9f\x1bh/\xa3\xa8\xd8arG\x8a\xbb"qQi\x02\xe8)2\x9bv\x071\x1a^\x16\xee8\x87\x91*GA\xb9A\xa2#\n3\xa5\x06\x0e\xbd\xb0\xca\x06\xc8Bp&\x83\xb0r\xb9~\xdco\xa6\xa4\x87\x12\x02y\ty\xdc\xfa-\xbd1+\x02\x82\xe7\x9f\xc5{<Y\x1e\x9d\xc3\xfbf\x96AC\xe1|4\xbcA\xcew\\\x86\x81&\xa1hP\x12\xc2\x9aL\xc9\'\xe8\xaa\xec\xa1Vx\xbfOc\xa1\x8e\xeah\xff\x8d\x0f\x84\x9e\xd9\x16\x8b\xcc\xd0\xf8\xba\x7fm$e\xd9\x8b\x03\xc9\x1e\xd1\xbf\xc5\tP\xb9]hO\xbe+\xe6\x1f\xaa\x8bU\xdf\xbe\x8au\xf6\xa1\x155\x12\tK\xa0[\x04\x12c}\x04\t\xe5\x83J\x0e\x179;\xe7\x89\xa1\xbcA\xe1,\xb5,\xf8F\xbc\xca\x05\xd4x\xe9\x02\x142\x05\x8f\xe5F\n\xc98\xfb\x04"\x9d\xcc\xb7\x05yJ;\xbb\xd3\xaa_~\x19k\xb6\xdf\x0f{\x95\x94\xc2\xda\xac\xcf\xad\x04\xb2\x13\x9b#\x01\xa8l\xb3P[W\x9aA\xfa\xc9E\x9b\xb5\xe8\xa4\x16\x8b,\xf3\xc33\x8a\x7f\xf5]\xb2_\xec\xdaj\x0c5+\xbf(\xe1{\x04\xe0\xbc3\x95_\xbbm!\xc9D%l\x00\xd8{\x88\xee\xd7\xae\x0e>\xb7\x13b\xa4\x1a#\x1b\xde\x94\xbc\x08\x8f)R\xad)6\x892\xe1\xbd\xf5o\xcbE\xdf\x10\x97\xe8\xd8\xdb\xdf\x10Py\xdd\xf6\x1f@\x9a\xce\xdd$R\xb1\xc9\xfa@\x1a’\xf0\x0c\x1f\x88\x0e;t\xa3\xcb\x9e\xfa-X\x94J\x8e\x90\xb7\xad\xd2\xea\x85\x9aJ\xf7\x1d\x8a\x07$m\x9d\x82\xdb4_\xf3\x80:9\xc8\x8e\tJ6\xd3Z\x89h\xaa\x03\xd1n\xb2\xc5\x81\xc1\xe7-I\x14\xba+\xe3\xe1e\xcfCF\xba$X#\x82\xba\xa8g\x7f\xe8\t\xa39\xd6)\x85\xa8,\tt\xb3\xb5\xbd\x97\xd2\xf4\x9d\xd4\x82\xd6\x9d\xdb\xc9!\x0f\x06\xf7?\xb6>\r]\xeb\xd6\x88\xf102’\xe3’, form=‘der’), domains: [u’website’]
2017-07-04 23:02:01,162:DEBUG:acme.client:Requesting issuance…
2017-07-04 23:02:03,834:DEBUG:acme.client:JWS payload:
{
“resource”: “new-cert”,
“csr”: “xx”
}
2017-07-04 23:02:06,668:DEBUG:root:Sending POST request to https://acme-v01.api.letsencrypt.org/acme/new-cert:
{
“header”: {
“alg”: “RS256”,
“jwk”: {
“e”: “AQAB”,
“kty”: “RSA”,
“n”: “x”
}
},
“protected”: “xx”,
“payload”: “xx”,
“signature”: “xx”
}
2017-07-04 23:02:16,370:DEBUG:urllib3.connectionpool:“POST /acme/new-cert HTTP/1.1” 201 1543
2017-07-04 23:02:17,387:DEBUG:acme.client:Received response:
HTTP 201
content-length: 1543
strict-transport-security: max-age=604800
boulder-request-id: C9yyDHRpIgt1a77a0zILZWBFcVbQoyBjCLPp5sWyu3o
boulder-requester: 13915366
expires: Tue, 04 Jul 2017 23:02:15 GMT
server: nginx
connection: keep-alive
link: https://acme-v01.api.letsencrypt.org/acme/issuer-cert;rel=“up”
location: https://acme-v01.api.letsencrypt.org/acme/cert/038907e0d88dc265d73494ea9eced3bcf1de
pragma: no-cache
cache-control: max-age=0, no-cache, no-store
date: Tue, 04 Jul 2017 23:02:15 GMT
x-frame-options: DENY
content-type: application/pkix-cert
replay-nonce: xx

xx==
2017-07-04 23:02:17,438:DEBUG:acme.client:Storing nonce: 3rVx9Y4fhdO_vcxtr5yuJPscnxFdyo1HsLd0E6_qTyM
2017-07-04 23:02:27,665:DEBUG:root:Sending GET request to https://acme-v01.api.letsencrypt.org/acme/issuer-cert.
2017-07-04 23:02:27,935:DEBUG:urllib3.connectionpool:“GET /acme/issuer-cert HTTP/1.1” 200 1174
2017-07-04 23:02:27,937:DEBUG:acme.client:Received response:
HTTP 200
content-length: 1174
strict-transport-security: max-age=604800
boulder-request-id: 1GRt_Bb9Re-dPIpX8u1nx5kMhLBOgZtiyvM2Xb8B0rs
expires: Tue, 04 Jul 2017 23:02:27 GMT
server: nginx
connection: keep-alive
pragma: no-cache
cache-control: max-age=0, no-cache, no-store
date: Tue, 04 Jul 2017 23:02:27 GMT
x-frame-options: DENY
content-type: application/pkix-cert
replay-nonce: xx

xx==
2017-07-04 23:02:29,279:DEBUG:certbot.storage:Writing new private key to /etc/letsencrypt/archive/website/privkey2.pem.
2017-07-04 23:02:29,286:DEBUG:certbot.storage:Writing certificate to /etc/letsencrypt/archive/website/cert2.pem.
2017-07-04 23:02:29,292:DEBUG:certbot.storage:Writing chain to /etc/letsencrypt/archive/website/chain2.pem.
2017-07-04 23:02:29,294:DEBUG:certbot.storage:Writing full chain to /etc/letsencrypt/archive/website/fullchain2.pem.
2017-07-04 23:02:41,327:DEBUG:certbot.storage:Writing new config /etc/letsencrypt/renewal/website.conf.new.
2017-07-04 23:02:42,364:DEBUG:certbot.renewal:no renewal failures`

Could you post “ls -alR /etc/letsencrypt/{archive,live}”? Preferably without redacting it at all, but modifying the domains isn’t really a problem, as long as it’s not ambiguous.

Result of command line sudo ls -alR /etc/letsencrypt/{archive,live} :
`/etc/letsencrypt/archive:
total 8
drwx------ 2 root root 4096 juil. 6 21:49 .
drwxr-xr-x 8 root root 4096 mai 4 23:03 …

/etc/letsencrypt/live:
total 8
drwx------ 2 root root 4096 juil. 6 22:50 .
drwxr-xr-x 8 root root 4096 mai 4 23:03 …`

Did you attempt to do anything to delete your certificates, or do you have any program you can think of that would do that? The log file you posted showed Certbot creating files under these directories, and now you don’t have anything there anymore.

Unfortunately, I did it myself. I thank that would solve my issue.

Now, it’s possible to erase all Let’s Encrypt certificates to restart with a new situation. Without certificate I can’t restart my service, and everything is done until the 6th of July :frowning:

Have a nice night !

I think I forgot about some of the details that you previously shared.

As you may have seen, deleting existing certificates does not affect rate limits in any way. Meanwhile, new issuances of identical certificates are still completely prevented by the rate limits, which is probably why you can’t issue anything right now.

The duplicate certificate limit is calculated per week. According to my calculations, you would be allowed to issue one more certificate under this rate limit in about two hours from now. Alternatively, if you have another domain name, including a subdomain, you could issue another certificate that covers both names without being affected by this particular rate limit at all.

Once you have a working certificate again, it would be interesting to understand why the renewal process originally misfired and renewed your certificates every day. The most helpful thing for that would be to see the log files from /var/log/letsencrypt associated with the individual times that Certbot decided to perform a renewal. You might still have these files from when that happened a few days ago.

You are right, I can create a new certificate for my domain. My service is now up. Many thanks !
Now, how can erase the old certificates ?

Regarding the question “why the renewal process failed ?”, I don’t know.
What do you mean by “associated with the individual times that Certbot (…)” In addition with my crontab script, Certbot check itself to renew the certificate ? Sorry I don’t understand this sentence…

To facilitate your research, may I send you by email all the log files ? If yes, could you give me your professionnal email outside the forum (to avoid spams).

Have a nice day.

I think you already did, using rm!

You pointed out that for some reason the certificate was renewed every day, leading to the original "Too many certificates already issued for exact set of domains" error message. Each of these events involved Certbot running and should have been logged in a log file in /var/log/letsencrypt, and it's those log files that I wanted to see. :slight_smile:

That would be great. It's my forum username plus @eff.org.

Hello,

I want also to delete the certificates, not only localy on my server, but also for the website itself. When I check with https://crt.sh/ my website, I obtain the list of my old certificates (cf. below).

I will send you by email all my logfiles. Please, destroy files as soon as issue is fixed :grin:

Certificates are public documents, the fact that somebody successfully requested and was issued each particular certificate is logged to the Certificate Transparency system. The logs are tamper evident precisely in order to make it difficult to delete anything from them. So you won’t be able to make that happen.

Yeah, the best you can do is revoke the certificates, but they’re on the certificate transparency log permanently.

It’s not possible to destroy old certificates. The certificate is a file that continues to exist on every computer that has a copy of that file.

Increasingly, different projects collect and archive old certificates for security, transparency, and Internet research purposes.

The crt.sh interface allows you to search

which is a database established to ensure that old certificates are publicly preserved and archived, mainly in order to detect attacks and misbehavior by certificate authorities. Let’s Encrypt cooperatives with Certificate Transparency voluntarily but Google is going to require all certificate authorities to do so starting around the end of this year, in order to have their certificates accepted by the Google Chrome family of browsers.

If you have the private key or account key associated with a certificate, you can revoke the certificate. Revocation is implemented, among other things, by having the certificate authority issue a new, additional statement that it no longer considers the certificate to be valid (but the certificate itself still exists wherever people have copies of).

I got all of the logfiles from @IssueFindings by e-mail. The situation is very puzzling because the certificates (as we can see from crt.sh) were successfully issued and then apparently saved in cert2.pem, etc., but on every subsequent day the renewal script saw the old version as the current version, and therefore did a new renewal, again saving in cert2.pem each day. This suggests that the symlinks were never updated or that cert2.pem never existed or something.

@IssueFindings, apart from deleting everything, did you previously edit or modify anything in /etc/letsencrypt, such as renewal configuration files, the names of directories, or the destination of symbolic links?

2 Likes

Many thanks for all these answers and damned because I can’t totaly erase old certificates… Is there any security risk to leave them not revoked ?

Regarding my server configuration, I touch nothing before the issue on 5th of july. I used an automatic renewal based on my crontab : @reboot sleep 15 && sudo service nginx stop && sudo certbot renew --quiet --rsa-key-size 4096 && sudo service nginx start I detect this issue because my nginx server was down.

Do you think I can restart my automatic renewal ? If not, what is the best solution ?

Have a nice day.

@erica, do you remember any bug in Certbot 0.10.2 that would prevent updating symlinks on renewal in some circumstances? I remember that you fixed something important in storage.py around that time but i don’t remember precisely what it was.

@IssueFindings, I would suggest restarting the automated renewal (maybe once per day instead of @reboot?) and then keeping an eye out around September 9 to see if the repeated renewal is happening again.

@schoen, not in 0.10.2…