When I try to generate a certificate using Ansible I got an error: Error new cert: CODE: 500 RESULT: {u'status': 500, u'type': u'urn:ietf:params:acme:error:serverInternal', u'detail': u'Error finalizing order'}",
My domain is: nic.cpa
I tried to debug it using https://letsdebug.net, I got the following message:
INVALID DOMAIN
" **“nic.cpa” is not a valid domain name that Let’s Encrypt would be able to issue a certificate for. **
// cpa : 2019-06-10 American Institute of Certified Public Accountants
cpa
And you can resolve it on Internet. It is fully delegated:
$ dig nic.cpa +short
54.245.106.105
Could you please help me to figure out why Let’s Encrypt can’t validate it?
The version of my client is
$ ansible --version
ansible 2.8.5
I am using acme_certificate module. It works well for other domains, so I am confident the problem is on Lets Encrypt side not able to check that .cpa is a valid TLD.
How many times have you tried to issue a certificate? Can you try again?
If the TLD is too new for Let’s Encrypt to know about it, you should get a “Name does not end in public suffix” error, like this:
$ sudo -H certbot certonly --staging --webroot -w /srv/www/certbot -d $(uuidgen).zzz
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
An unexpected error occurred:
The server will not issue certificates for the identifier :: Error creating new order :: Cannot issue for "81787d33-9c4f-470f-97d1-31a7eaf14740.zzz": Name does not end in a public suffix
Please see the logfiles in /var/log/letsencrypt for more details.
The error you got suggests something else went wrong; I don’t know what. Let’s Encrypt staff could look it up from the server logs. It might have been some sort of temporary issue.
If I try to issue certificates for .cpa domains, it fails with an ordinary validation error – on the other hand, your attempts might be succeeding at validation and failing at a later step that I can’t test.
Let's Encrypt uses a version of the PSL a version that does contain cpa.
But Let's Debug was using an older version. I've updated it now, so you shouldn't see that problem anymore.
That comes from the actual issuance process, from what I can tell. So, things like:
Getting your account and authz info from the database
Extracting info out of the CSR
Creating the precertificate
Getting SCTs
Signing the final certificate
There could be something busted in that process that prevents a cpa domain from succeeding, but as mentioned, we have no way to know until a staff member appears.
But what you can do is try to do the same process from a different ACME/Let's Encrypt account, to try rule out issues that are specific to yours. That does help, sometimes.
It may be due to the fact that first time I generated DNS challenge when this TLD was not delegated on Internet. And then I was validating other certs including this one. I got an error of course but it could save some info somewhere.
do the same process from a different ACME/Let’s Encrypt account, to try rule out issues that are specific to yours
Do you mean to generate DNS challenge using another Lets Encrypt private key ?
Coincidentally enough, when zlint was last updated, the pull request was opened and merged on a Tuesday, and it was deployed to production on the Thursday nine days later.
No issues were found with nic.cpa. If you are having problems with creating an SSL certificate, please visit the Let's Encrypt Community forums and post a question there.
Related DNS TXT record is deployed and I obtained a new DNS challenge (the same value). After I tried to collect SSL cert again, it failed with
I tried to use another Let's Encrypt account, deployed another DNS challenge but the result is the same:
{"changed": false, "msg": "Error new cert: CODE: 500 RESULT: {u'status': 500, u'type': u'urn:ietf:params:acme:error:serverInternal', u'detail': u'Error finalizing order'}", "other": {}}
Does it mean the change is not deployed in production or do I have another problem now?