Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

tls: handshake failure #1

Open
pana67 opened this issue Jun 30, 2017 · 11 comments
Open

tls: handshake failure #1

pana67 opened this issue Jun 30, 2017 · 11 comments

Comments

@pana67
Copy link

pana67 commented Jun 30, 2017

Hi,
I am trying to make work enrolment lets encrypt certificate for our ASA firewall / VPN gateway.
I am able to communicate with ASA REST API, I installed I hope all required software on internal linux server (Debian),but when I run the command for enrolment I obtain error:

  • The following errors were reported by the server:

    Domain: fw.networksys.cz
    Type: tls
    Detail: remote error: tls: handshake failure

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    you have an up-to-date TLS configuration that allows the server to
    communicate with the Certbot client.

it seems to me the certificate is not published on ASA but I do not know how to debug it - I enclose the whole CLI output for details
certbot-asa-log.txt
.
On the ASA there is already certificate from our internal (private) CA - I do not know how the certificate from certbot-asa script is setup on the ASA, as there is no attribute for the name of output interface.

Thank you for any help.
@chrismarget
Copy link
Owner

I've seen this error myself recently.

The issue was that when LE's authenticator connected to the ASA to validate the challenge certificate, it wasn't able to establish a TLS session with the ASA.

I didn't figure out what was wrong, but suspect it's an SSL cipher support issue on the ASA. At the time I had the problem, the same LE authenticator (same IP address, anyway) was able to talk fine with one of my ASAs, but not with the other.

There was no time to debug the problem at that time, so I didn't pursue it further.

What version of software is running on the ASA? I'll see if I can replicate the problem.

@pana67
Copy link
Author

pana67 commented Jun 30, 2017 via email

@chrismarget
Copy link
Owner

So, if the failure is happening where I think it's happening...

If you run 'show run | inc trustpoint|trust-point' repeatedly on the ASA while the plugin is operating, you should see a temporary trustpoint and SNI configuration appear briefly.

Once those are installed, we're just waiting for the LE authenticator to come look at them.

At this point, you should be able to see the TLS failure if you're watching packets (fairly easy to spot), or with the right debug incantation on the ASA (I'm not sure what that might be).

I'll fire up an ASA in the lab.

@pana67
Copy link
Author

pana67 commented Jun 30, 2017 via email

@pana67
Copy link
Author

pana67 commented Jun 30, 2017 via email

@pana67
Copy link
Author

pana67 commented Jun 30, 2017 via email

@chrismarget
Copy link
Owner

Yup, this is where I wound up last time it happened.

It's not really an issue with the plugin, but the TLS service on the ASA rejecting LE's TLS client.

I couldn't figure it out last time, but I intend to take another crack at it.

@chrismarget
Copy link
Owner

Pavel, can you test something for me?

You'll have to be quick: During the interval when the ASA is configured to serve up the challenge certificate, but before LE gets around to checking... Please try to delete the ssl trust-point acme-challenge_blah domain blah line from the ASA configuration?

My hope is that the error will change from something about TLS handshaking to a challenge validation failure (indicating that TLS succeeded).

I'm finding that with that directive in place I have trouble with the TLS handshake on my test box.

@chrismarget
Copy link
Owner

I think we're running into this Cisco bug. An ASA upgrade is going to be required.

@pana67
Copy link
Author

pana67 commented Jul 3, 2017 via email

@chrismarget
Copy link
Owner

I'm confident that the bug I mentioned is your problem. There's a couple of options for verifying that:

  1. Downgrade to 9.3(2). The problem should go away.

  2. Manually:

  • Hit CTRL-C a couple of times as soon as certbot says INFO:certbot.auth_handler:Waiting for verification... Don't let certbot clean up after itself. The ASA will be left with a trustpoint, RSA keypair and an ssl trust-point directive that weren't there before. You can remove these later.
  • Look at the ssl trust-point line. The last argument is a very long domain name ending in .acme.invalid
  • Knock against the ASA using openssl: openssl s_client -connect <ASA-IP-Address>:443 -servername <long-domain-name.acme.invalid>

The s_client command should fail with SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure. That's the bug.

Remove the ssl trust-point line, or change the -servername argument to some other value and the s_client command should succeed (meaning you don't get your Linux shell prompt back). At that point, type GET / HTTP/1.0 <CR><CR> and the ASA should spit some HTML at you (through the TLS session created by openssl).

It seems that any TLS connection which matches the SNI filter specified by the ssl trust-point <blah> domain <blah> directive will have a problem because of this bug. Frankly, I'm surprised you got past the openssl s_client step in the plugin's readme, because it relies on SNI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@chrismarget @pana67