Hi, I'm running ISPConfig 3.2.7p1 in a (Ubuntu 20.04.3 LTS (Focal Fossa)) with a couple of client websites all with Lets Encrypt certificates. The SSL certs all work fine in browser and produce no errors or warnings but one site needs to connect via CURL to another external website I have no control over. So, the website I host uses wordpress and needs to initiate connections via wp_remote_post to an external API that end up with error: cURL error 35: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure via terminal if I try: curl -svo /dev/null https://api-domain.com --connect-to ::XXX.XX.XX.IP 2>&1 | egrep -v "^{.*$|^}.*$|^* http.*$" or just: curl -v /dev/null https://api-domain.com I get: * Connecting to hostname: XXX.XX.XX.IP * Trying XXX.XX.XX.IP:443... * Connected to XXX.XX.XX.IP (XXX.XX.XX.IP) port 443 (#0) * ALPN, offering h2 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS alert, handshake failure (552): * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure * Closing connection 0 If I test my server with the same calls I get * Connecting to hostname: XXX.XX.XX.MYIP * Trying XXX.XX.XX.MYIP:443... * Connected to XXX.XX.XX.MYIP (XXX.XX.XX.MYIP) port 443 (#0) * ALPN, offering h2 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * Server certificate: * subject: CN=MY-DOMAIN-NAME.com * start date: Jan 26 15:21:07 2022 GMT * expire date: Apr 26 15:21:06 2022 GMT * subjectAltName: host "MY-DOMAIN-NAME.com" matched cert's "MY-DOMAIN-NAME.com" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. > GET / HTTP/1.1 > Host: MY-DOMAIN-NAME.com > User-Agent: curl/7.74.0 > Accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Date: Wed, 26 Jan 2022 16:25:28 GMT < Server: Apache < Link: <https://MY-DOMAIN-NAME.com/wp-json/>; rel="https://api.w.org/", <https://MY-DOMAIN-NAME.com/wp-json/wp/v2/pages/14>; rel="alternate"; type="application/json", <https://MY-DOMAIN-NAME.com/>; rel=shortlink < Vary: Accept-Encoding < Transfer-Encoding: chunked < Content-Type: text/html; charset=UTF-8 < * Connection #0 to host XXX.XX.XX.MYIPleft intact ****************************************************** I don't think this is related to my ISPConfig client website? or is it? Any help would be appreciated.
No, this sounds like a problem in the plugin/theme making the https request. They should ideally fix the certificate in that site; a poor alternative would be to configure the curl environment to ignore certificate errors when calling that API.
Thanks Jesse, So the error would be on my end with the auto generated ISPConfig -> Let's encrypt SSL? Because outside the plugin/theme... via my server terminal I get those CURL errors.
Maybe I misunderstood - is the api you are connecting to hosted on your ISPConfig server? I thought the wordpress site was on your server, connecting to a remote api (somewhere else on the internet); if the api endpoint is on your server then the certificate issue should be fixable on your server as well.
No the API is on an external server I do not control. The api client (wordpress) is on my ISPConfig server and gets those errors trying to connect either via wp_remote_post or via terminal curl
Testing the external API server SSL. This server supports TLS 1.0 and TLS 1.1. Grade capped to B. And ispconfig is trying to connect to above API server with tlsv1.3. Is there a way to initiate the connection with tlsv1.1 or 1.2?
What's connecting to that API is the CMS that you installed via the PHP packages that you installed from the Linux Distribution that your system is using, ISPConfig is not involved in the connection to that API server at all. Or in other words, even if you would remove ISPConfig completely from your server, the problem would stay the same.
Hi till... thanks for taking a look. The ispconfig is an Ubuntu server with latest packages of openssl and curl. $ curl --version curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3 Release-Date: 2020-01-08 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp Features: AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets $ openssl version OpenSSL 1.1.1f 31 Mar 2020 From ispconfig machine... via terminal... if I try to connrct to the API server I get: curl -v https://api-domain.com * Connecting to hostname: XXX.XX.XX.IP * Trying XXX.XX.XX.IP:443... * Connected to XXX.XX.XX.IP (XXX.XX.XX.IP) port 443 (#0) * ALPN, offering h2 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS alert, handshake failure (552): * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure * Closing connection 0 I will send you PM.
I've tested the connection from a Debian 10 system and I get handshake errors as well, so the API server is broken. Code: * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS alert, handshake failure (552): * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure * Closing connection 0 curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure and Code: * ALPN, offering h2 * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS alert, handshake failure (552): * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure * Closing connection 0 @Jesse Norell posted you the two possible solutions already, either you contact the provider of the API and ask him to fix the config issue on his server, or change the code of your CMS so that curl does not try to use TSL 1.3. I would recommend that you first try to contact the person or organization that runs this API system and if they can't or won't fix it, then try to modify your code to limit curl connection tls version. But I just did a short test and received e.g. for: curl --tlsv1.1 --tls-max 1.1 ..... an error: Code: * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS alert, internal error (592): * error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available * Closing connection 0 curl: (35) error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available
Exactly till, I also tried curl --tlsv1.1 --tls-max 1.1 and got the same error. The CMS is wordpress trying a wp_remote_post... if above worked would need to check if there's a way via wp-config.php or some other file to force TLSv1.1... because I don't want to change anything at server level that might affect other ispconfig sites. Thanks very much till.
Contact the maker of the plugin or theme which is a problem. They should fix their API, or at least fix their code to work with their API.
The solution is to lower the openssl sec level in ispconfig machine (if you are worried about it... create a dedicated web machine to run it). MinProtocol = TLSv1.2 CipherString = DEFAULT@SECLEVEL=1
that isn't a solution, it's a workaround.. what happens when support for TLS1.2 is dropped? their api should support the latest available TLS versions.
What happens when TLS 1.3 is dropped? As you can see from above, no one offered this solution to me... So I posted it here in order to help anyone who wants to use it. Your solution would be to drop this ispconfig client because of an external api? I rather like to keep clients, specially if they have several websites. Sometimes I wonder who you guys are (because i do see you in a lot of threads... helping)! And, I wonder if you would present such solutions at a professional level to your customers But thanks anyhow.
when TLS 1.3 is dropped, everyone should be using TLS 1.4 or TLS 1.5 or whatever the successor is. i'm not saying that you shouldn't do what you did, or that you should drop the client, although my post may come across as harsher than intended. i was just stating that reducing the level of security should not be seen as a solution, but a temporary workaround. the solution would be for the api provider to support the latest security protocols, and if they refuse, to start looking for an alternative provider for that service, in the same way, if a major security flaw was found in a wordpress plugin on a clients site, you'd ask the developer for that plugin for a security update, if they didn't provide one, or claim to be working on one, you'd look for an alternative, secure plugin that provided the same functionality, after all tls 1.3 was finalized 4 years ago, it's been the default in windows 10 for the last 18 months, they should, at the minimum, be able to disclose their plans for supporting tls 1.3, it's not like tls 1.3 is some new alternative that's just been sprung on them.
