EntityAlreadyExistsException

[dlapiduz]

EntityAlreadyExistsException

[tschoonj]

I get the same errors, but the certificates did get updated though...

[weavejester]

Yeah, I just noticed that as well. I think it's because the -new certificate is still around, and the code expects it to have been removed.

[tschoonj]

I doubt that, I renewed my certificates three months ago with the exact same command and there was no error message back then.

[weavejester]

This line in the installer suggests that the certificate name + '-new' should be renamed to name. If that step didn't happen for whatever reason, that would leave a -new certificate lying around, which may be causing the problem.

[michaelandrew]

I'm having a similar issue, it would appear that client.delete_server_certificate in that file is not being called or succeeding as even without the + '-new' suffix, the issues are still apparent, just without -new appended at the end. The installer initially created domain.com then domain.com-new when renewing. After that it doesn't seem to work on the renewal process.

[michaelandrew]

By moving the client.delete_server_certificate method before the client.upload_server_certificate I managed to get this to work successfully with the -new suffix as it should. Will PR but not 100% sure what impact this may have on creating new certificates.

[weavejester]

Is it possible to get a new release with this fix? Currently certbot-s3front stops working after the first time you use it.

[weavejester]

Hm, my particular problem might be due to a issue with AWS. I've got an unused certificate which can't be deleted, but fortunately can be renamed. Perhaps that was why certbot-s3front got stuck in the first place.

[dlapiduz]

I cut a release anyway so it should be ok now.

[tschoonj]

After installing the latest version of certbot-s3front (which includes @michaelandrew's patch) and its dependencies I still get the same error:

letsencrypt --agree-tos -a letsencrypt-s3front:auth --letsencrypt-s3front:auth-s3-bucket easyrng -i letsencrypt-s3front:installer --letsencrypt-s3front:installer-cf-distribution-id E3N3TVNGX8O8B7 -d easyrng.tomschoonjans.eu --renew-by-default --text
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for easyrng.tomschoonjans.eu
Found credentials in environment variables.
Calling s3:put_object with {'Body': u'some-string', u'Bucket': 'easyrng', 'Key': u'.well-known/acme-challenge/some-other-string', 'ACL': 'public-read'}
Starting new HTTPS connection (1): easyrng.s3.amazonaws.com
Waiting for verification...
Cleaning up challenges
Starting new HTTPS connection (1): easyrng.s3.amazonaws.com
Starting new HTTPS connection (1): iam.amazonaws.com
An unexpected error occurred:
EntityAlreadyExistsException: An error occurred (EntityAlreadyExists) when calling the UploadServerCertificate operation: The Server Certificate with name le-easyrng.tomschoonjans.eu-new already exists.
Please see the logfiles in /var/log/letsencrypt for more details.

IMPORTANT NOTES:
 - Unable to install the certificate
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/easyrng.tomschoonjans.eu/fullchain.pem. Your
   cert will expire on 2017-08-15. To obtain a new or tweaked version
   of this certificate in the future, simply run certbot again with
   the "certonly" option. To non-interactively renew *all* of your
   certificates, run "certbot renew"

Any thoughts?

[tschoonj]

Oh and this time my certificates really did not get uploaded to AWS

[yungchin]

It seems that there's interference here between a bug in cloudfront, which has now been fixed, and the IMHO improper fix in 2f7cf93.

What I found after using certbot-s3front through several updates:

1. a certificate named le-mydomain.name which is impossible to remove through the IAM CLI (raising a DeleteConflict if you try it manually through boto)
2. a certificate named le-mydomain.name-new which is also non-removable, but that's proper because it is actually used by the cloudfront distribution

So I think what happened here is that, 90 days ago when I ran the renewal, the cloudfront bug mentioned above prevented deletion of the old cert, and therefore the rename also failed. That explains this remark

I get the same errors, but the certificates did get updated though...

... which was exactly what I saw at the time.

Here's my workaround for now:

1. roll back certbot-s3front to version 0.2.0
2. connect to IAM manually using boto3 and move the old cert out of the way:

import boto3
client = boto3.client('iam')
client.update_server_certificate(ServerCertificateName="le-mydomain.name",
                                 NewServerCertificateName="le-mydomain.name-zombie")
client.update_server_certificate(ServerCertificateName="le-mydomain.name-new",
                                 NewServerCertificateName="le-mydomain.name")

3. run your certbot renewal as you would normally
4. contact AWS to get rid of the zombie cert (which I'm about to do now)

[dlapiduz]

@yungchin @michaelandrew I just pushed a new version that should kill the EntityAlreadyExistsException error once and for all. Please let me know if you give it a try.