Getssl: curl error: 35

Help
#1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: holtain.net

I ran this command: /usr/local/bin/getssl -u -a -w /etc/getssl

It produced this output: getssl: curl error : 35

My web server is (include version): Server version: Apache/2.2.3

The operating system my web server runs on is (include version): CentOS 5 (almost retired system)

My hosting provider, if applicable, is: wizards.co.uk

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): getssl ver. 2.33

This runs as a crom job, on 11/ January 2021 I got the expected output-
Check all certificates
holtain.net: certificate is valid for more than 30 days (until Mar 28 08:08:00 2021 GMT)

But every run since then I get the curl error

#2

Can you tell us more about the context of the curl error? Perhaps copy/paste more of the output?

#3

That us all of the output-

[root@nitrogen ~]# /usr/local/bin/getssl -u -a -w /etc/getssl
getssl: curl error : 35
[root@nitrogen ~]#

#4

I took a look at the code of getssl, and that error occurs when it fails to update itself from GitHub.

Could you try running this command to see more about what's going wrong?

curl -v https://raw.githubusercontent.com/srvrco/getssl/master/getssl

Also, just to confirm that this is where it's trying,

grep CODE_LOCATION /usr/local/bin/getssl

#5

curl -v https://raw.githubusercontent.com/srvrco/getssl/master/getssl

[root@nitrogen ~]# grep CODE_LOCATION /usr/local/bin/getssl
CODE_LOCATION="https://raw.githubusercontent.com/srvrco/getssl/master/getssl"
curl --user-agent "$CURL_USERAGENT" --silent "$CODE_LOCATION" --output "$TEMP_UPGRADE_FILE"
[root@nitrogen ~]#

#6

What version of curl are you using? And what version is your OpenSSL library? I think it's very strange that it can't connect to Github..

#7

Connected fine on 11 January, but ever since it's failed

curl -V
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.36 zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz unix-sockets
[root@potassium ~]#

openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017
[root@potassium ~]#

#8

Hi @Niamh

searching Google, the first result:

curl version 7.29.0 was released on February 6 2013. The following 52 security problems are known to exist in this version.

No, no, no: That's not something to use today.

1 Like
#9

I also have my doubts about the OpenSSL version:

https://www.cvedetails.com/version/229672/Openssl-Openssl-1.0.2k.html

I would urge @Niamh strongly to update both software packages! And perhaps other packages with exploitable vulnerabilities too.

1 Like
#10

Well, CentOS-type systems often release patches for vulnerabilities without updating the version number, which makes it tough to figure out exactly what is and isn't patched. But CentOS 5 has been out of support for some time, so there may very well be important patches that haven't been applied.

The past that it says "SSLv3" in the curl output is certainly concerning, though I don't know if maybe it just tried that after trying other protocols that it couldn't get to work. I have a wild guess that maybe the version of curl you have is old enough to not support TLSv1.2, and that Github disabled earlier TLS versions, but I can't find in my quick searching any documentation of when or if Github did that so I may just be barking up the wrong tree.

What happens if you try curl to other URLs, like say,

curl -v https://valid-isrgrootx1.letsencrypt.org

Maybe play around with adding --tlsv1.0 or --tlsv1.2 in there too, just to see if that might be part of the issue?

#11

[root@nitrogen ~]# curl -v https://valid-isrgrootx1.letsencrypt.org

  • About to connect() to valid-isrgrootx1.letsencrypt.org port 443
  • Trying 52.9.173.94... connected
  • Connected to valid-isrgrootx1.letsencrypt.org (52.9.173.94) port 443
  • successfully set certificate verify locations:
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt
    CApath: none
  • SSLv3, TLS handshake, Client hello (1):
    SSLv3, TLS handshake, Server hello (2):
    SSLv3, TLS handshake, CERT (11):
    SSLv3, TLS handshake, Server key exchange (12):
    SSLv3, TLS handshake, Server finished (14):
    SSLv3, TLS handshake, Client key exchange (16):
    SSLv3, TLS change cipher, Client hello (1):
    SSLv3, TLS handshake, Finished (20):
    SSLv3, TLS change cipher, Client hello (1):
    SSLv3, TLS handshake, Finished (20):
    SSL connection using DHE-RSA-AES128-SHA
  • Server certificate:
  •    subject: /CN=origin.letsencrypt.org

  •    start date: 2021-03-10 15:00:41 GMT

  •    expire date: 2021-06-08 15:00:41 GMT
  • SSL: certificate subject name 'origin.letsencrypt.org' does not match target host name 'valid-isrgrootx1.letsencrypt.org'
  • Closing connection #0
  • SSLv3, TLS alert, Client hello (1):
    curl: (51) SSL: certificate subject name 'origin.letsencrypt.org' does not match target host name 'valid-isrgrootx1.letsencrypt.org'
#12

That domain

supports Tls.1.0, 1.1 and 1.2

raw.githubusercontent.com supports only Tls.1.2

So your curl doesn't use Tls.1.2.

You have to update it.

PS: Try to connect

curl -v https://www.server-daten.de/

That should fail, same reason.

#13

That's not the correct certificate for https://valid-isrgrootx1.letsencrypt.org/! See for example here: SSL Server Test: valid-isrgrootx1.letsencrypt.org (Powered by Qualys SSL Labs) You should get a certificate for the exact hostname `` with serial number 0486ee38b244b64ca17b706f617a4ecc4e1c.

However, I see that you only get that certificate with SNI enabled. When I use -noservername to disable SNI with OpenSSL s_client, I get the origin.letsencrypt.org certificate too.

SNI is a very widely spread feature of SSL/TLS. I don't recall coming across any SSL/TLS client not having that feature, so this is a first.

Please upgrade your cURL as your version is missing essential features. (Although probably not related to the github site issue mentioned here.. That hostname works fine without SNI.)

#14

apache version 2.2.3 (which your webserver says) is released in Fri, 28 Jul 2006. where did you install centos from(if I google cuurretly it's centos 5)? as it's new site I'd format the system and just start from newer image
you just have too old software stack.

#15

There's a bodge-
CODE_LOCATION="http://raw.githubusercontent.com/srvrco/getssl/master/getssl"

#16

It's a very old site, CentOS 5 went eol 4 years ago. It has a few personal things on it but not much else.

#17

Then it's time to update.

#18

CentOS 5 doesn't update to later releases, it's start from scratch, not worth it for this legacy stuff

#19

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