Renew certificate

[pascalcarmoni]

How you renew the certificate?
Do i need to do the script from the step 7 in your quick start page every 3 monts?

[bseddon]

Yes, you have to renew every three months. The certificates issued by Let's Encrypt only last that long.

The trick to renewing is just to run the process again but with a different IdentifierRef passed into New-ACMEIdentifier. Run through the process again and you have a new certificate.

[pascalcarmoni]

I dont understand...Change this?
PS> New-ACMEIdentifier -Dns myDomain.com -Alias dns1
I need to kept the same domaine name....

[bseddon]

Yes, you will keep the domain name but change the alias.

New-ACMEIdentifier -Dns myDomain.com -Alias something-else

The alias is a name you create. It does not mean anything. It is an identifier that links some information needed by Let's Encrypt with your domain name.

My recommendation is that you add the date to the alias. Something like:

New-ACMEIdentifier -Dns myDomain.com -Alias "myDomain.com-2016-09-22"

[qgustavor]

It's possible to keep the same private key?

[1trevor]

You don't need to create a new identifier to renew a cert. You can just start with New-ACMECertificate.

[Sparticuz]

Ok, so basically these are the steps to get a renew cert? (Just changing the Alias for each renewal?)

New-ACMECertificate dns1 -Generate -Alias cert2
Submit-ACMECertificate cert2
Get-ACMECertificate cert2 -Exportxxxxx "path\to\cert2.xxx"

[ebekker]

Yep, that's about it. You'll be able to keep doing this every ~90 days until your validation for the domain name(s) on the certs expire, which I believe is a little over 1 year, then you'll have to re-validate your ownership of the domains again.

[ebekker]

Closing the ticket -- if anyone still has problems or more questions, keep commenting.

[mcdurdin]

I wrote up my experiences with automating renewal of certificates with ACMESharp on my blog, in case anyone else finds it useful: https://marc.durdin.net/2016/11/automating-certificate-renewal-with-lets-encrypt-and-acmesharp-on-windows/

[qpongo]

The 'Expires' date on my dns identifier hasn't changed after I created a new certificate from that alias. ?? It still expires in 10 days. ??

I did exactly the same thing mentioned by Sparticuz...

New-ACMECertificate dns13 -Generate -Alias mycert13_170110
Submit-ACMECertificate mycert13_170110
md c:\_SSL\mydomain.com
Update-ACMECertificate mycert13_170110
Get-ACMECertificate mycert13_170110 -ExportKeyPEM "c:\_SSL\mydomain.com\mycert13_170110.key.pem"
Get-ACMECertificate mycert13_170110 -ExportCsrPEM "c:\_SSL\mydomain.com\mycert13_170110.csr.pem"
Get-ACMECertificate mycert13_170110 -ExportCertificatePEM "c:\_SSL\mydomain.com\mycert13_170110.crt.pem" -ExportCertificateDER "c:\_SSL\mydomain.com\mycert13_170110.crt"
Get-ACMECertificate mycert13_170110 -ExportIssuerPEM "c:\_SSL\mydomain.com\mycert13_170110-issuer.crt.pem" -ExportIssuerDER "c:\_SSL\mydomain.com\mycert13_170110-issuer.crt"
Get-ACMECertificate mycert13_170110 -ExportPkcs12 "c:\_SSL\mydomain.com\mycert13_170110.pfx"
Get-ACMECertificate mycert13_170110 -ExportPkcs12 "c:\_SSL\mydomain.com\mycert13_170110_pw.pfx" -CertificatePassword 'mySecret'

Maybe something changed? Maybe the 'expires' date gets updated later?

I say that because I noticed that I created a new challenge then ran

Update-ACMEIdentifier dns13

and it returned an expires date of 3 days from now but when checking again later it returned exactly 60 days from today.

>> Am I missing something or just impatient?

I thought that I did not need to start with all the challenge steps as well?

i.e.

New-ACMEIdentifier -Dns mydomain.com -Alias dns13b
Complete-ACMEChallenge dns13b -ChallengeType dns-01 -Handler manual

_<insert/change the TXT record on my DNS server>_

Submit-ACMEChallenge dns13b -ChallengeType dns-01
(Update-ACMEIdentifier dns13b -ChallengeType dns-01).Challenges | Where-Object {$_.Type -eq "dns-01"}

[bseddon]

Here's what I've deduced based on experience and read what relevant information I can find.

When Let's Encrypt issues a certificate for a given key the record in the Let's Encrypt servers will only allow that key to be used for (I think this number is correct but you can check) 292 days (why 292? Who knows).

When you initially create a certificate for a key the certificate will be valid for 90 days. You can regenerate but when using the same key eventually the certificate will run up against the 292 day limit.

An ACMESharp 'idenfierRef' or 'alias' is an alias for an LE key. When you use the -generate option you are asking ACMESharp to request a new certificate using some key associated with an alias. Initally this command will be able to generate a 'new' certificate with a 90 day expiration period. But eventually, the new 'new' certificate will hit the 292 day limit and, so, the certificate expiration will be shorter than 90 days.

My recommendation is that you always create a new alias so a new key is created. @whereisaaron has published a script that handles the dns-01method if you are using AWS Route 53

https://github.com/whereisaaron/acmesharp-update-certificate

[qpongo]

@bseddon wrote "My recommendation is that you always create a new alias so a new key is created. @whereisaaron has published a script that handles the dns-01method if you are using AWS Route 53"

And, yes, I reviewed this batch file that @whereisaaron created -- I understand all the steps and think that I'm doing the same thing. NOTE: I'm using dns-01 with some very inexpensive dns/email provider that I bought with a coupon (occupational hazard -- lol) so I must make updates through their web interface - i.e. by hand.

This morning I am confused. (And I thought that I understood how it's all supposed to work).

#1. I took the advice and created a new identifier, certificate, etc. for the Danish subdomain of my Qpongo.eu coupon site...

Import-Module ACMESharp

New-ACMEIdentifier -Dns dk.qpongo.eu -Alias qdns1013_170117
Complete-ACMEChallenge qdns1013_170117 -ChallengeType dns-01 -Handler manual
_Normally, I'd update the TXT record in my dns but nothing changed so I continued._
Submit-ACMEChallenge qdns1013_170117 -ChallengeType dns-01
(Update-ACMEIdentifier qdns1013_170117 -ChallengeType dns-01).Challenges | Where-Object {$_.Type -eq "dns-01"}

New-ACMECertificate qdns1013_170117 -Generate -Alias qcert1013_170117
Submit-ACMECertificate qcert1013_170117

Update-ACMECertificate qcert1013_170117
Get-ACMECertificate qcert1013_170117 -ExportKeyPEM "c:\Qpongo-SSL\dk.qpongo.eu\qcert1013_170117.key.pem"
…

(as far as I can tell these are the exactly same steps as this batch file but I list them here for completeness)

#2. But running "Update-ACMEIdentifier qdns1013_170117" still says that the certificate identifier expires in two weeks even though I just created a new one.

IdentifierPart : ACMESharp.Messages.IdentifierPart
IdentifierType : dns
Identifier : dk.qpongo.eu
Uri : https://acme-v01.api.letsencrypt.org/acme/authz/R_d....
Status : valid
Expires : 1/30/2017 2:45:03 AM
Challenges : {, , }
Combinations : {1, 0, 2}

#3. HOWEVER, I installed the .pfx (actual certificate) and it says that it expires in 90 days.

>> What am I not understanding?

Why is the date not changing with the newly created identifier (alias)?

PS Here are all the commands from Aarons script...

	Line 371:             $result = New-ACMEIdentifier -VaultProfile $VaultProfile -Dns $domain -Alias $alias
	Line 376:             $result = Get-ACMEIdentifier -VaultProfile $VaultProfile $alias
	Line 404:                 $result = Complete-ACMEChallenge $alias -VaultProfile $VaultProfile -ChallengeType $ChallengeType -Handler $ChallengeHandler -HandlerParameters $ChallengeParameters
	Line 456:             $result = Submit-ACMEChallenge $alias -VaultProfile $VaultProfile -ChallengeType $ChallengeType
	Line 492:         $result = Update-ACMEIdentifier $alias -VaultProfile $VaultProfile -ChallengeType $ChallengeType
	Line 538:                 $result = Update-ACMEIdentifier $alias -VaultProfile $VaultProfile -ChallengeType $ChallengeType
	Line 557:         $result = Complete-ACMEChallenge $alias -VaultProfile $VaultProfile -ChallengeType $ChallengeType -Handler $ChallengeHandler -HandlerParameters $ChallengeParameters -Clean
	Line 593:         $result = Get-ACMECertificate $certalias -VaultProfile $VaultProfile
	Line 651:             $result = Submit-ACMECertificate $certalias -VaultProfile $VaultProfile
	Line 662:     $result = Update-ACMECertificate $certalias -VaultProfile $VaultProfile
	Line 675:         $result = Update-ACMECertificate $certalias -VaultProfile $VaultProfile
	Line 685:         $result = Get-ACMECertificate $certalias -VaultProfile $VaultProfile -ExportPkcs12 $filepath -Overwrite
	Line 689:         $result = Get-PfxCertificate -FilePath $filepath

[bseddon]

I think what you are being confused about is the meaning of 'expiry'. When a challenge is submitted using the http-01 method the challenge attempt by Let's Encrypt will succeed or fail right away.

When using dns-01 I think things are different because it's a step that is not necessarily in the certificate applicant's control. Because DNS servers are usually run by a third party, and are subject to TTL values, you may have entered your new TXT record value but that value may take days to propagate to other DNS servers even if the host company make the changes to their own servers immediately.

Let's Encrypt servers will try to validate the DNS TXT entry many times but not indefinately. I think the expiry date in the update response is the date before which the LE servers will attempt to access your DNS TXT record. A grace period. After this date the attempt to validate the alias will be abandoned and marked as invalid.

The actual certificate expires in 90 days as it should.

[ebekker]

I think it might be a little bit different still -- the Identifier expiration is when the Identifier verification will expire. In other words you have 10 more days to request additional certs against this Identifier. After 10 days you'll need to submit a new Identifier request (even though it's for the same DNS name) and verify it again, i.e. complete the DNS or HTTP challenge to prove you own/control it.

[qpongo]

Thanks to both of you.

@bseddon wrote: "...you may have entered your new TXT record value but that value may take days to propagate to other DNS servers..."

In my case it is verified almost immediately but the expiration never changes, even when I create a completely new identifier and that has me confused (more later).

@ebekker wrote: "I think it might be a little bit different still -- the Identifier expiration is when the Identifier verification will expire."

• Yes, this is exactly what I understood -- the weird thing for me is that I've never been able to move this date up once the initial verification gave me 60 days on the identifier certification.
• And, yes, certificate expiration is independent of this and I've always gotten a 90 day term for certificates.
• And, again, registering new identifiers for the same domain do not change the identifier expiration (or provide new TXT challenges -- I get the same value) even when I specify completely different alias values.

Here are actual screen prints from registering a NEW subdomain under our Polish Coupon site -- Qpongo Poland

Notice that I registered a new identifier for test.qpongo.pl with the alias testpl and notice that it initially gave me a expiration 7 days from now.

Now I request and complete the dns-01 challenge by adding the record to my DNS server and the expiration date of the certificate bumps up to 60 days from today.

Certificates that I create with this identifier will be good for 90 days and so far, this identifier expiration date has never changed, even when I create a new identifier for the same domain. Some identifiers are expiring this month so I guess I'll figure out what happens after that.

The only thing that I do differently from the script by @whereisaaron is that I am not specifying -VaultProfile << not sure if that's related.

[ebekker]

Hmm, the only thing I can think of is that the Identifier before it is validated has a 7-day expiration, in order to restrict the window of time when the challenges can be completed, and the Identifier after it is verified (challenges satisifed) is given a 60-day expiration.

If I recall correctly, the verified Identifier expiration used to be considerably longer, but I might be thinking of just the Let's Encrypt staging environment, and maybe in PROD it is shorter for increased security.

I didn't jot these thresholds down in the reference sheet so they may not be published anywhere.

[ebekker]

Confirmed, the challenge tokens expire after 1 week thanks to @jsha 's comment here.

[drsox]

I recently had a right mess trying to re-validate (complete a challenge on) an Identifier. In the end I just created a new Identifier.

All the commands I tried didn't seem to extend the Expiry date held against the Identifier - even though the re-submitted Challenge showed as valid and up to date.

Generally looks like it might be easier just to script my stuff to, every single time, create a new identifier and re-submit challenges even if the previous one is nowhere near expiry.

[ebekker]

So the Authorization expiration period used to be 10 months but apparently has recently has been changed to 60 days. So the numbers you're seeing appear to be in line with this info.

[ebekker]

Oh, and there were some API changes made back in August that apparently recycles existing authorizations so that if you try to validate an existing DNS Identifier that has more than 24 hours left before it expires, you will receive back the same existing authorization object -- i.e. it will not be renewed/reiussed with a new expiration date.

Thanks to @jsha and @srvrco for the details.

So all's well!

[qpongo]

Thanks @ebekker for the link -- very helpful!

Automatic recycling of authorization objects

Estimated date: August 3, in staging as of July 14

Clients can reuse existing, validated authorization objects, but this is difficult, in part because Boulder doesn't yet offer the list of authorizations specified in ACME. Most clients create a new authorization object for each issuance. This is generally fine.

However, a tiny handful of misconfigured instances attempt validation and issuance every minute. The issuances fail due to rate limiting, but each attempt creates a new authorization object, cluttering up our database.

We've found a backwards-compatible way of making authz reuse possible without client changes. If a client creates a new authorization object, and we already have a valid authorization object with more than 24 hours until expiration, we'll return the URL of that new authorization object. Clients are free to POST to that authorization object and Boulder will return 200, but will not re-attempt validation. On polling, clients will immediately see status = valid. We've tested Certbot and found it works great with this setup, and we expect other clients will have no problems either.