I ran this command:
renewed from Certify The Web UI
It produced this output:
NewIdentifier : ACMESharp.AcmeClient+AcmeWebException: Unexpected error
+Response from server:
+ Code: BadRequest
+ Content: {
“type”: “urn:acme:error:malformed”,
“detail”: “Error creating new authz :: DNS name does not have enough labels”,
“status”: 400
}
My web server is (include version):
IIS
The operating system my web server runs on is (include version):
Windows 2016
My hosting provider, if applicable, is:
N/A (AWS IaaS)
I can login to a root shell on my machine (yes or no, or I don’t know):
Yes - RDP
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No
I had no problem creating the certificate; but now that I am trying to renew I am getting this error. I looked around, and I don’t see any incomplete domain names. Is there a way to find out what label does LetsEncrypt trip over?
I’m not sure… Does Certify have debug logs? The HTTP request it made to Let’s Encrypt certainly contains the name (well, encoded or encrypted), but the error response doesn’t.
2017-12-23 00:40:05.383 -07:00 [Information] Beginning Certificate Request Process: ATIMS_Denver_Config
2017-12-23 00:40:05.590 -07:00 [Information] Attempting Domain Validation: denver-config.atimsonline.com
2017-12-23 00:40:14.981 -07:00 [Information] Could not begin authorization for domain with Let's Encrypt: denver-config.atimsonline.com Could not register domain identifier - [12:40 AM] NewIdentifier : ACMESharp.AcmeClient+AcmeWebException: Unexpected error
+Response from server:
Code: BadRequest
Content: {
"type": "urn:acme:error:malformed",
"detail": "Error creating new authz :: DNS name does not have enough labels",
"status": 400
} ---> System.Net.WebException: The remote server returned an error: (400) Bad Request.
at System.Net.HttpWebRequest.GetResponse()
at ACMESharp.AcmeClient.RequestHttpPost(Uri uri, Object message)
--- End of inner exception stack trace ---
at ACMESharp.AcmeClient.AuthorizeIdentifier(String dnsIdentifier)
at Certify.ACMESharpCompat.ACMESharpUtils.NewIdentifier(String alias, String dns, String vaultProfile)
at Certify.VaultManager.BeginRegistrationAndValidation(CertRequestConfig requestConfig, String identifierAlias, String challengeType, String domain)
2017-12-23 00:40:14.981 -07:00 [Information] Validation of the required challenges did not complete successfully.
Using the information you shared I was able to find the failure logs on our side. It looks like you have a configuration error with your Certify settings. It appears to be trying to request a certificate for a domain "Denver-demo", which isn’t a valid DNS name for the public internet:
I also opened an issue with the Certify developers to try and make it easier to avoid this error in the future. Thanks for opening a forum thread about it!
OK, there will be a fix for this in the next release of Certify SSL Manager (v3.0.10, probably early next week). @virshu can you confirm that version of Certify you are currently on?
If there is any place I can look outside UI - I am happy to do so (and I realize that it’s a question to Certify, and not to Lets Encrypt - but I see that you are working together
As far as UI - this is the only reference I see to the domain, and it is fully qualified (see screenshot).
I removed both domains and tried to generate new certificate. It tells that it failed 10 times before, and it will try again in 48 hours. Not sure if it applies to auto renew only, or I am in a penalty box for 2 days
Finally, I upgraded just yesterday to 3.0.9. Is the fix in 3.0.10 better error message? Or it will actually fix the bug of not getting a certificate?
Thanks @webprofusion! One of the the things I was confused about in the original poster's log output:
This lists a real domain name, denver-config.atimsonline.com, which made me think that was the domain name Certify was trying to validate. What was that domain, and could you also update Certify to log the domain name it's trying to validate?
Hi Jacob, that confused me too which is what prompted me to think it was an old version somehow. Investigating further now. Certainly in my tests that’s always been the domain in question that shows there, except when we used to have a threading issue with the logger (which I don’t believe we have now).
The version is shown on the About tab. If you find any suspected bugs like this one, start a new issue at https://github.com/webprofusion/certify/issues - otherwise I might not see the question.
Now that you’re definitely on the latest version can you try:
Hit ‘Test’ under Advanced for your managed site ‘ATIMS_Demo’, if that’s not OK then we need to investigate (or you can try deleting it and adding again, as below).
If that’s OK, just hit ‘Request Certificate’ and it should complete normally.
If that’s still not working:
Delete your ATIMSDemo managed site in Certify and hit New Certificate again (to add the managed site again).
You can then optionally hit ‘Test’ under Advanced to check your server is responding OK.
Assuming ‘Denver-demo’ is no longer in your bindings, then just use ‘Request Certificate’ to get your certificate
if that fails, email me at apps {at} webprofusion.com and we can go into further detail on the diagnostics. Or we can discuss here if you like.
I wondered if the configuration was messed up somehow due to change of bindings on the IIS site (so the UI doesn’t quite match the IIS bindings).
Regarding the ‘48 hours’ email - it’s normal for renewals to sometimes fail then work on the next attempt, so the app’s background service will attempt to resolve failed renewals less frequently as they continue to fail (so after 1hr, then after another 2hrs, then after another 3hrs). Note that at any time you can just go into the app and hit ‘Request Certificate’ to perform a renewal attempt. I assume this certificate request has just never worked so far (so neither will renewals)?
Once we get to 48hrs, that’s the most we will wait between retry attempts. We will then send you an email saying that renewals are failing for that site (if Notify Primary Contact On Renewal Failure is checked) and on subsequent failed attempts. You can turn this off by switching off the notification or by just unchecking ‘Enable Auto Renewal’ for the site, if you don’t need it to be working right now.
I’ll do the troubleshooting that you described. In the meantime I wanted to clarify that initial certificate request succeeded only renewal failed. It probably failed multiple times; but the engineer whose email is in the primary contact is on vacation, so we never learned that renewal was failing. I want to say that we didn’t make any changes after initial successful request… but I wouldn’t trust my clients when they say so; so I don’t expect you, either
I did delete and requested new certificate (instead of renewal); but now new requests are failing as well.
OK, it’s not that important. Let me follow troubleshooting steps that you described
@virshu thanks, if the request worked initially and is now failing it almost definitely means the IIS configuration changed in the meantime (perhaps an app was installed into a previously empty web application etc).
There is a new release out now (3.0.10) with slightly updated logging and a filter on hostname-only bindings (to remove machine-name style bindings from the cert request). If your request still fails please check the log, you can email it to me at apps {at} webprofusion.com if you want to try getting help with it. Basically if you can access http://<yourdomain.com>/.well-known/acme-challenge/configcheck then you should be good to go but sometimes you need to delete the existing .well-known folder first if it was created by another user etc.
After additional troubleshooting (thank you @webprofusion) the problem is solved. Here is the summary.
We have two sites on this server: denver-demo.atimsonline.com and denver-config.atimsonline.com. Both names resolve to the same IP. Using SNI, they both are running on 443 for https. I thought that I couldn’t have them both listen to 80; even for different URLs (IIS would complain that it can only start one, and not allow another one).
So, I created a third site; just listening on port 80, and just to respond to certificate request. I thought I was smart, but… When Certify The Web tries to renew for, say, denver-demo, it creates a magic file in denver-demo directory; but then letsencrypt tries to read it from the third site (the one listening on port 80) and of course fails.
Sure, I was able to renew manually – bind 80 on first site; renew; “unbind”; bind 80 on the second site; renew; “unbind”. But it wouldn’t work for automatic renewal. Fortunately, turns out that IIS complaint is bogus. I can run two sites on the same port 80, specifying URL the same way I am specifying it for https binding!
-