Azure Web App automatic certification renewal stopped working

I got a message from the “Let’s Encrypt Expiry Bot” that my Azure certificates will expire soon:
Your certificate (or certificates) for the names listed below will expire in 19 days (on 02 Apr 20 00:23 +0000). Please make sure to renew your certificate before then, or visitors to your website will encounter errors.
The same error in the Troubleshoot section in web app TLS/SSL settings is:
Certificate with Thumbprint 11f6a8011f534bf2e29ba459bca547442107b35a bound to the hostname will expire in 13 days .

I have been using Let’s Encrypt for my Azure Web App certificates now for over 1,5 years and so far I have never got expiration messages like these. Instead all has worked automatically fine with the 90 day certificate renewals.

I have not touched anything in my Web App TLS/SSL settings during the last year, so I am wondering what is causing this problem. The installation of Let’s encrypt in Azure was very difficult and I hope I don’t have to touch anything there…

My questions are:

  • why has the automatical renewal stopped working after working fine in over a year?
  • can I check it with some command i.e in the Portal or in Kudu Diagnostic console?
  • is it possible to do a manual renewal from the Azure Portal? This would be fine with me.
  • I still have 13 days to do something. Could it be that the renewal is delayed for some reason?

Best regards
Bengt Bredenberg
Premisol Oy
Helsinki, Finland

My domain name for the first app is:
I have four other web apps using Let’s encrypt in the same domain behaving exactly the same way

There is some issue with your DNS.

it looks like your authoritative servers only respond with a cname record instead of all of them how they’re supposed to:

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>>                             
; (2 servers found)                                                                                                     
;; global options: +cmd                                                                                                 
;; Got answer:                                                                                                          
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43095                                                               
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1                                                    
;; WARNING: recursion requested but not available                                                                       
;; OPT PSEUDOSECTION:                                                                                                   
; EDNS: version: 0, flags:; udp: 4000                                                                                   
;; QUESTION SECTION:                                                                                                    
;     IN      A                                                                               
;; ANSWER SECTION:                                                                                              3600 IN      CNAME                                         
;; Query time: 36 msec                                                                                                  
;; SERVER: 2620:1ec:bda::8#53(2620:1ec:bda::8)                                                                          
;; WHEN: Thu Mar 19 12:39:12 CET 2020                                                                                   
;; MSG SIZE  rcvd: 95 

while the answer section it’s supposed to look like this:


Thanks 9peppe
I can see that your debug program shows that there is an error in the dns settings but I have no
idea of how to tackle this problem. How can I get the authoritative server to respond in a different
way? Shouldn’t this problem be an all inside Azure thing? And I haven’t done any changes there.
Here is a copy of my DNS zone if it is possible to send it like this

BR. Bengt

Hi @Bengtbr

there is a check of your domain, ~~one hour old -

Host T IP-Address is auth. ∑ Queries ∑ Timeout C yes 1 0
C yes Name Error yes 1 0 A Dublin/Leinster/Ireland (IE) - Microsoft Corporation No Hostname found no A Dublin/Leinster/Ireland (IE) - Microsoft Corporation No Hostname found no

You have some CNAME entries. So CAA entries of your CNAME values are checked, there is one buggy.

But your main domain has (see your screenshot) the same ip like your CNAME entries.

So you can replace the CNAME with an A-entry and that ip.

Then the buggy name server

Mar 19 11:48:27 unbound[8399:0] info: reply from <>
Mar 19 11:48:27 unbound[8399:0] info: query response was nodata ANSWER
Mar 19 11:48:27 unbound[8399:0] info: wrong 0x20-ID in reply qname

isn’t checked.

Thank you JuergenAuer
Before I do anything irreversible I just have some more questions.
Is it the last www CNAME which is in error. It seems somehow misplaced here and
the error seems to come from that row?
Will the problem be fixed by removing this row?
Your suggestion to replace the CNAME with an A-entry and ip. To which host does it refer?
Thanks again for your very fast replies.
BR. Bengt

There is nothing “irreversible”. You can always restore your current CNAME entry.

I must admit that this is a bit too complicated for me. I removed the last entry with name www because it seemed irrelevant but it didn’t help at all.So my DNS zone is as before but without the www row.
Your suggestion was to replace a CNAME entry with an A entry with ip
Do you mean the row
premimanager CNAME 3600 should be replaced by a row premimanger A 3600
or should both rows be there?
Is it really good to change dns names to fixed ip:s?
Could you please help me with this and show how the dns rows should look like.
BR Bengt

no. a CNAME record must be by itself, no other records can be present. you need to remove it to add an A record.

A is an ipv4 address, AAAA is an ipv6 address, but CNAME is neither, it is just a reference to another domain name, it clones its records.

If it’s better to go with one or the other just depends on how often the addresses will change and who updates the final A and AAAA records.


You can’t. CNAME or individual definitions.

You have already such a row.

The name server of one of these CNAME destinations is buggy. But you can’t fix that name server, so you shouldn’t use it.

After creating the certificate, you can undo these changes. Not good, manual, but better then an expired certificate.

Now I have changed the rows to A-based and doesn’t give error notices anymore

Azure private key certificates still gives error messages (see below), but I suppose this will be fixed in some time window.
Can I do a manual certificate refreshes for Let’s encrypt in Azure?

If they’re expired, you can tell your client to renew. I don’t know how to tell your client that, though.

The certificates will expire in 12 days so I have still time to do corrections. Even though I did the changes to the DNS zones, this did not affect the renewal process. When I checked in Microsoft Azure WebJobs (from Kudu Let’s encrypt) Functions.RenewCertificate gives the error :
Microsoft.Azure.WebJobs.Host.FunctionInvocationException : Microsoft.Azure.WebJobs.Host.FunctionInvocationException: Exception while executing function: Functions.RenewCertificate —> Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: AADSTS7000222: The provided client secret keys are expired.
Have anyone seen this error before?
The settings are shown in Azure Portal Web App Service Configuration and I find there among others letsencrypt:ClientId and letsencrypt.ClientId.
How is the client secret keys related to these?
The ClientSecret has been the same all the time

Even if there probably were some problems with DNS settings on my Azure site, the main problem with the certificate renewal failure was that the Client secret key for the Let’s encrypt App service had expired,
which it seems to after a 1-2 year use. For this problem there is an excellent answer on site:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.