0.3.0 Beta 2: Could not obtain directory: Crypto negotiation failed: Connection reset by peer

[rkrx]

0.3.0 Beta 2: Could not obtain directory: Crypto negotiation failed: Connection reset by peer

[kelunik]

Do you get that repeatedly?

[rkrx]

Everytime I run the client, yes.

[kelunik]

Does the same happen with the 0.2.x versions?

[rkrx]

With the latest 0.2.14 release, the error message reads as follows:

PHP Warning:  stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages:
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol in phar:///root/lets-encrypt/acme-client.phar/vendor/amphp/socket/lib/functions.php on line 318

SSL generally works with php and configuration also looks reasonable:
php -r 'print_r(openssl_get_cert_locations());'

Array (
    [default_cert_file] => /usr/lib/ssl/cert.pem
    [default_cert_file_env] => SSL_CERT_FILE
    [default_cert_dir] => /usr/lib/ssl/certs
    [default_cert_dir_env] => SSL_CERT_DIR
    [default_private_dir] => /usr/lib/ssl/private
    [default_default_cert_area] => /usr/lib/ssl
    [ini_cafile] =>
    [ini_capath] =>
)

[kelunik]

Which version of PHP do you use? Can you reproduce the issue on other systems?

[rkrx]

That system is running on PHP7.0.
I can't reproduce the error on any other system.

[kelunik]

@DaveRandom @trowski Any ideas what might be causing this?

[DaveRandom]

SSL23_GET_SERVER_HELLO:unknown protocol seems to suggest that the client and server don't share any compatible protocol versions.

According to SSL Labs the servers at acme-v01.api.letsencrypt.org support TLS 1.0 - 1.2, SSL 2/3 are disabled and TLS 1.3 is not supported (i.e. pretty typical configuration at the moment).

Given that, possible causes:

• PHP has been built against an ancient OpenSSL version that does not support TLS - unlikely; I don't know if PHP 7 can even be built against something that old
• TLS is disabled in the system openssl.conf - I don't think this would matter, I think artax explicitly specifies sane defaults here?
• The connection is being intercepted and something is attempting to transparently proxy the connection using only protocols that the client doesn't support (i.e. essentially a poor attempt at MITM)

Output of openssl s_client -connect acme-v01.api.letsencrypt.org:443 might reveal more useful info, it would also be worth checking that the DNS resolves to something sensible

[rkrx]

Thank you for the detailed description. I will look into this and ask my network administrator to look at the firewall settings. My suspicion is that SSL interception is active there and the firewall itself does not offer the necessary protocols.

If this is actually the case, then the error message of the LE-client should refer to this case. Shouldn't happen often, but if it happens, then you're looking for a long time.

[DaveRandom]

tbh I sort of doubt you have a network-wide proxy interception issue, as browsers would be borking as well - most of them have had SSLv3 disabled by default for a long time.

If you are able to run these commands on the machine where you were having problems and post the full output here, it might give us something to work with:

nslookup acme-v01.api.letsencrypt.org or dig acme-v01.api.letsencrypt.org or (if neither of those tools are readily available) ping acme-v01.api.letsencrypt.org

This is the one that will really tell you what's happening with regard to the SSL layer: openssl s_client -connect acme-v01.api.letsencrypt.org:443 - if this successfully establishes a connection it may hang waiting for input, if you don't see any output for ~5secs then ctrl+C and take the output up to that point.

[rkrx]

Sorry for the late response. @DaveRandom The issue is probably not based on anything caused by our firewall.

The command openssl s_client -connect acme-v01.api.letsencrypt.org:443 works with www.google.com:443 but not with lets-encrypt:

# openssl s_client -connect acme-v01.api.letsencrypt.org:443
CONNECTED(00000003)
3073595072:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 305 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1528401218
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

Adding -servername to the command, makes no difference on that machine:
openssl s_client -connect acme-v01.api.letsencrypt.org:443 -servername acme-v01.api.letsencrypt.org

Invoking this command against LE on other machines works just fine. But on the other hand, this particular machine is a vm-guest with a vanilla ubuntu 16.04 on a pretty standard hardware-setup. The only thing that is different in this case is the corporate firewall (sophos .. something) - an additional independent hardware layer my other machines don't sit behind... I also had other strange problems on that vm like having rare conditions while querying MX-records. I will further investigate...

[DaveRandom]

It appears from that output, as best as I can work out, that the server is not presenting a certificate, which to me seems to suggest that the socket is not connected to the expected destination.

What happens if you curl https://acme-v01.api.letsencrypt.org/directory? You should get the JSON document you will see if you visit that URL in a browser, if you don't then it's definitely something to do with your network configuration rather than an issue with and specific client software.

This definitely feels like something external is interfering with your internet-bound traffic - and the fact that Google seems to work OK would fit with that, as Google is likely "permitted".

[xsrf]

Okay, I had a similar issue today when setting up a new Windows Server.

Warning: stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed in phar://***/acme-client.phar/vendor/amphp/socket/lib/functions.php on line 318
Could not obtain directory.
Kelunik\Acme\AcmeException: Issuance failed, not all challenges could be solved. in phar://***/acme-client.phar/src/Commands/Issue.php:104

Executing C:\Users\Administrator>php -r "echo file_get_contents('https://acme-v01.api.letsencrypt.org/directory');" also failed (I don't have the error message but it said something with "TLS handshake timeout" and "setting up crypto failed"). I then opened https://acme-v01.api.letsencrypt.org/directory in the browser, which worked fine.
I executed C:\Users\Administrator>php -r "echo file_get_contents('https://www.google.com/');" and C:\Users\Administrator>php -r "echo file_get_contents('https://www.letsencrypt.org/');" and both worked fine.
I then tried C:\Users\Administrator>php -r "echo file_get_contents('https://acme-v01.api.letsencrypt.org/directory');" again, and it worked.
After that, the acme client also worked fine.
I really don't know why, but the problem is gone...

[kelunik]

@xsrf Thanks for reporting, quite strange.

I think there's not much I can do from my side, these seem to be system-dependent edge cases.

[rkrx]

I think I've found my problem. For some reason, our firewall cached the DNS record for v01.api.letsencrypt.org, but never released it. The IP did not match the current IP (IPs?) of v01.api.letsencrypt.org and may have been assigned to another letsencrypt machine without SSL certificate for that particular IP/machine. The cache in the firewall was cleared manually and now everything works as expected.

@xsrf Could you try pinning letsencrypt's current IP in your Windows host file and see if this might solve your problem?