Incorrect validation certificate for tls-sni-01 challenge.

[kkkelvinkk]

Thanks for your great tools. I am currently trying to use it on CentOS 7.4 Machine. After spending several hours, I figure out that the tools must be run using Python requests between 2.9.0 and 2.17.3. Now I can run the certbot command successfully. However, the following errors occurred. The real hostname is replaced by hostname.domain.hk, and the real public IP address is replaced by 1.1.1.1. Current ASA software is asa982-15, and the rest api is 1.3(2)-200. Would you please advise ?

Domain: hostname.domain.hk Type: unauthorized Detail: Incorrect validation certificate for tls-sni-01 challenge. Requested e6c8ca0d41f4b8c8f457490a6cb360f4.772828c96c35f97af5b2f0d1ec1a465d.acme.invalid from 1.1.1.1:443. Received 1 certificate(s), first certificate had names "asa-mgmt"

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. 2017-12-03 16:10:06,394:INFO:certbot.auth_handler:Cleaning up challenges 2017-12-03 16:10:08,728:ERROR:certbot.log:Exiting abnormally: Traceback (most recent call last): File "/usr/bin/certbot", line 11, in load_entry_point('certbot==0.19.0', 'console_scripts', 'certbot')() File "/usr/lib/python2.7/site-packages/certbot/main.py", line 861, in main return config.func(config, plugins) File "/usr/lib/python2.7/site-packages/certbot/main.py", line 698, in run certname, lineage) File "/usr/lib/python2.7/site-packages/certbot/main.py", line 85, in _get_and_save_cert lineage = le_client.obtain_and_enroll_certificate(domains, certname) File "/usr/lib/python2.7/site-packages/certbot/client.py", line 357, in obtain_and_enrollcertificate certr, chain, key, = self.obtain_certificate(domains) File "/usr/lib/python2.7/site-packages/certbot/client.py", line 318, in obtain_certificate self.config.allow_subset_of_names) File "/usr/lib/python2.7/site-packages/certbot/auth_handler.py", line 81, in get_authorizations self._respond(resp, best_effort) File "/usr/lib/python2.7/site-packages/certbot/auth_handler.py", line 138, in _respond self._poll_challenges(chall_update, best_effort) File "/usr/lib/python2.7/site-packages/certbot/auth_handler.py", line 202, in _poll_challenges raise errors.FailedChallenges(all_failed_achalls) FailedChallenges: Failed authorization procedure. hostname.domain.hk (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested e6c8ca0d41f4b8c8f457490a6cb360f4.772828c96c35f97af5b2f0d1ec1a465d.acme.invalid from 1.1.1.1:443. Received 1 certificate(s), first certificate had names "asa-mgmt"

[chrismarget]

The error indicates that the servers at LetsEncrypt are connecting to your ASA for validation, but it's giving them the wrong certificate. Specifically, it's returning the management certificate (the trustpoint we created manually), rather than the certificate with the subject name that satisfies their challenge.

Two possibilities:

1. You're co-mingling the public and management names of your ASA. Read through the guide paying particular attention to 'asa' vs. 'asa-mgmt' or whatever I called them.
2. Cisco's SNI feature is broken on your platform. This would not be the first time, but I've not seen it broken in exactly this way before.

If (2), while the script is waiting for validation, bail out with CTRL-C. There will be 3 temporary configuration elements left behind:

• a trustpoint
• an ssl trust-point directive referencing that trustpoint
• a keypair

You can delete these manually.

So, with these elements hanging around, do show run | include trust-point. Notice the domain .acme.invalid.

Check to see if it's working with:

:| openssl s_client -showcerts -connect <public IP>:443 -servername <blah.acme.invalid> | openssl x509 -noout -text

You should see a self-signed certificate with the acme.invalid name in the issuer and subject fields. It's the one from the temporary trustpoint that you saved from deletion by interrupting the script.

[kkkelvinkk]

Hi Chris,

For Point 1, I use ciscoasa.domain.com which is pointing to a public IP address, and asa-mgmt which is point to a private IP address. For Point 2, I have tried many times to press CTRL+C and stop the process(actually I don't know when should I press CTRL+C), but there is nothing ending with .acme.invalid when I use show run | include trust-point command. Seems the acme.invalid is not pushing to my Cisco ASA device. Any command I can use to debug the process, or should I directly send the log to you ?

Thanks.

[chrismarget]

You'll have a window to kill the script when it says "waiting for validation" or something along those lines. That's when the validators run by the LE folks should be coming around to check on the challenge. It usually takes a few seconds.

You can buy time by making ciscoasa.domain.com point at an IP address that doesn't respond. This way your ASA will be in the "waiting for validation" for a long time before the LE validators give up on getting a response from the (nonexistent) target.

Do you have an ssl trust-point <management trustpoint> domain asa-mgmt directive in the configuration? Some code releases don't allow the domain keyword at all in that command. Finding it missing would definitely be a problem.

[kkkelvinkk]

I tried use an invalid hostname ciscoasa.domain1.com, it makes no difference. Tried many times, no temporary certificate is generated.

The command ssl trust-point domain asa-mgmt directive is there.

Any idea ?

[chrismarget]

Interesting. You might be able to learn something from debugging the REST API on the ASA.

The way this works is this:

The temporary certificate is created by certbot code (not mine) on your Linux host. The plugin learns the path to the temporary certificate and key on the linux host. The plugin ingests those files, formats them for use by the ASA REST API. The certificate and key are loaded using dedicated methods on the ASA. An ssl trust-point <blah> domain <blah>.acme.invalid directive is loaded via the API's CLI function (there is no dedicated method for this configuration).

The key and certificate should by lying around somewhere on the certbot host at least until the script finishes. Maybe longer.