Let's Encrypt can't generate a cert for a recently delegated TLD

.cpa is a new TLD, it was delegated recently.

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. **

Domain doesn’t end in a public TLD"

I am not sure how Lets Encrypt checks if a domain is a public TLD but
https://publicsuffix.org/list/public_suffix_list.dat has information about it.

// 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.

Thank you for your awesome service.

Regards,
Slav

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.

1 Like

Unless it's changed, SCT errors say that they're SCT errors. Or at least some of them do.

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 ?

I have done some further investigating for you.

I have run Let’s Encrypt CA’s (Boulder) locally, and put an order through for nic.cpa.

The signing of the precertificate fails with:

boulder_1    | E055024 boulder-ca [AUDIT] Signing failed: serial=[ff51142d99db75e13af502dc85a6f4ee0296] err=[pre-issuance linting found 1 error results] lintErrors={"e_dnsname_not_valid_tld":{"result":"error"}}

(and from the client side, I see the “Error finalizing order” message).

We have a linter error with e_dnsname_not_valid_tld.

It looks like when zlint was added to the Boulder issuance process, it may have been forgotten that zlint needs to be updated together with the PSL.

I’ve filed an issue to update zlint. The upstream zlint project already has cpa listed.

4 Likes

_az, thanks a lot for that!

How long it usually takes to fix problems like this one?

Apparently there is no release this week, so you'll have to wait until at least October 4th.

1 Like

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.

https://letsencrypt.status.io/pages/maintenance/55957a99e800baa4470002da/5d5c3a81091fd21d10045eb3

If I see a related bug report was closed in Github, does it mean it was deployed into production?

I tried https://letsdebug.net/nic.cpa/65483 today and I got OK message:

All OK!

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

{"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": {}}

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?

Any help will be much appreciated.

It hasn't been deployed yet. Like another pull request that was merged the same day, I assume it will be deployed to production October 3.

1 Like

That’s correct.  

1 Like

The release schedule is described here. When code is merged to master it isn't automatically deployed.

1 Like

Thank you guys for all replies.

Frankly, I am impressed how quickly my issue was dealt with.
Thank you all. Great work.

2 Likes

Hi @slav,

You should now be able to issue for your .cpa domain without error. Please let me know if you are still encountering any difficulties.

Thanks for your patience,

3 Likes

It worked. Thank you very much.

2 Likes

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