Nagios check_ssl_cert error: SSL_CERT CRITICAL: Error: verify depth is 6 - ssl

I am setting up a Nagios/Icinga Monitoring system to monitor my enviroment. I would like to monitor my SSL certs with check_ssl_cert by it is not working on all sites.
My command:
/usr/lib/nagios/plugins/check_ssl_cert -c 7 -w 28 -H 141.85.37.43 -r /etc/ssl/certs/
returns:SSL_CERT CRITICAL: Error: verify depth is 6
(141.85.37.43 is just an example adress, not my own, but makes the same mistake).
if i try
# openssl s_client -connect ftp.myDomain.de:443
CONNECTED(00000003)
140037719324328:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:741:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 320 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
or
# curl https://ftp.myDomain.de:443 -v
* About to connect() to ftp.myDomain.de port 443 (#0)
* Trying 212.xxx.xxx.xxx...
* connected
* Connected to ftp.myDomain.de (212.xxx.xxx.xxx) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS alert, Server hello (2):
* error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
* Closing connection #0
curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
I am using a crushFTP on a ubuntu system called ftp.myDomain.de. I can use it with https://ftp.myDomain.de without any problem.
The cert is installed as a .pem file and was validated vom Thawte.
Is there something wrong with my cert?

I thing i got something. It is something with my SSL-Certs. I need to check with ssl version 3to get a working result.
Icinga plugins # openssl s_client -connect ftp.myDomain.de:443 -ssl3
i modified check_ssl_cert and added a new param -ssl to define version, just like the check-http offered:
http://pastebin.com/f46YQFg3 (need to post it there, to long for stackoverflow.com)
and can check it with
Icinga plugins # /usr/lib/nagios/plugins/check_ssl_cert -c 7 -w 28 -H "ftp.myDomain.de" -r "/etc/ssl/certs/" --ssl 3
SSL_CERT OK - X.509 certificate for 'ftp.myDomain.de' from 'Thawte DV SSL CA' valid until Jun 5 23:59:59 2015 GMT (expires in 676 days)|days=676;28;7;;
so my problem is kind of solved but i need to figure out what is the difference to my old - no workaround needed - certs and if i am in need to change something there?

I got in contact with the developer behind check_ssl_cert and he optimized and implemented my solution in an updated version.
https://trac.id.ethz.ch/projects/nagios_plugins/wiki/check_ssl_cert

I came across this same problem on a new Nagios box and tried the latest version of check_ssl_cert without success.
In the end the solution was to install expect.

I cannot say for certain, as I do not have all the necessary details, but it would seem that your certificate is fine, it is just that it's authentication chain is too long for check_ssl_cert to verify it.
The error message says "Verify depth is 6". This means that the certificate verify chain is >6 items long, not that it is necessarily failing.
Around line 228 and 205 in check_ssl_cert, you see the code:
exec_with_timeout $TIMEOUT "echo 'Q' | $OPENSSL s_client ${CLIENT} ${CLIENTPASS} -connect $HOST:$PORT ${SERVERNAME} -verify 6 ${ROOT_CA} 2> ${ERROR} 1> ${CERT}"
Note the -verify 6 in there limiting the maximum chain length to test. If you change this to -verify 16 (which might be overkill but should handle your chain) it will most likely work.

Related

Fixing git HTTPS Error: "bad key length" on macOS 12

I am using a company-hosted (Bitbucket) git repository that is accessible via HTTPS. Accessing it (e.g. git fetch) worked using macOS 11 (Big Sur), but broke after an update to macOS 12 Monterey.
*
After the update of macOS to 12 Monterey my previous git setup broke. Now I am getting the following error message:
$ git fetch
fatal: unable to access 'https://.../':
error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length
For what it's worth, using curl does not work either:
$ curl --insecure -L -v https://...
* Trying ...
* Connected to ... (...) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length
* Closing connection 0
curl: (35) error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length
Accessing the same HTTPS-source via Safari or Firefox works.
As far as I understand, the underlying error "bad key length" error is coming from OpenSSL/LibreSSL, this would be consistent with both git and curl failing after an OS upgrade.
This is the output from openssl:
$ openssl s_client -servername ... -connect ...:443
CONNECTED(00000005)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte TLS RSA CA G1
verify return:1
depth=0 ...
4593010348:error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length:
/System/Volumes/Data/SWE/macOS/BuildRoots/b8ff8433dc/Library/Caches/com.apple.xbs
/Sources/libressl/libressl-75/libressl-2.8/crypto/apple/hmac/hmac.c:188:
---
Certificate chain
...
---
No client certificate CA names sent
Server Temp Key: DH, 2048 bits
---
SSL handshake has read 4105 bytes and written 318 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-GCM-SHA384
Session-ID: 1FA062DC9EEC9A310FF8231F1EB11A3BD6E0778F7AB6E98EAD1020A44CF1A407
Session-ID-ctx:
Master-Key:
Start Time: 1635319904
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
I did try to add the server's certificates into a custom pem file and setting http.sslCAInfo, but that didn't work. As a workaround, I am currently using a proxy that decrypts/re-encrypts HTTPS traffic.
How do I configure git (or all LibreSSL users) to accept the server's certificate?
Setting this ENV var (in e.g. ~/.zshrc) worked for me
export CURL_SSL_BACKEND="secure-transport"
Unfortunately I can't provide you with a fix, but I've found a workaround for that exact same problem (company-hosted bitbucket resulting in exact same error).
I also don't know exactly why the problem occurs, but my best guess would be that the libressl library shipped with Monterey has some sort of problem with specific (?TLSv1.3) certs. This guess is because the brew-installed openssl v1.1 and v3 don't throw that error when executed with /opt/homebrew/opt/openssl/bin/openssl s_client -connect ...:443
To get around that error, I've built git from source built against different openssl and curl implementations:
install autoconf, openssl and curl with brew (I think you can select the openssl lib you like, i.e. v1.1 or v3, I chose v3)
clone git version you like, i.e. git clone --branch v2.33.1 https://github.com/git/git.git
cd git
make configure (that is why autoconf is needed)
execute LDFLAGS="-L/opt/homebrew/opt/openssl#3/lib -L/opt/homebrew/opt/curl/lib" CPPFLAGS="-I/opt/homebrew/opt/openssl#3/include -I/opt/homebrew/opt/curl/include" ./configure --prefix=$HOME/git (here LDFLAGS and CPPFLAGS include the libs git will be built against, the right flags are emitted by brew on install success of curl and openssl; --prefix is the install directory of git, defaults to /usr/local but can be changed)
make install
ensure to add the install directory's subfolder /bin to the front of your $PATH to "override" the default git shipped by Monterey
restart terminal
check that git version shows the new version
This should help for now, but as I already said, this is only a workaround, hopefully Apple fixes their libressl fork ASAP.
Edit: macOS 12.3 was officially released on march 13th, 2022 and the issue reported on this question has been fixed. Personally I have removed the workaround I had deployed and I suggest others do the same to keep up with the new versions.
Previous answer:
Apparently Apple has updated the LibreSSL version on macOS Monterey 12.3 developer beta 2 and later so this issue no longer happens. The stable 12.3 version is yet to be released but I have tested the developer beta and confirmed it fixed the issue for me, so there should soon be no need to deploy the workarounds mentioned on this question.
I guess macOS 12.3 will probably be released some time next month.
Spent almost 3 weeks to solve this on MACOS 12.1 Monterey. I was getting
fatal: unable to access 'https://.../':
error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length
Here's what worked:
Execute in a terminal with zsh (Z Shell):
echo 'export CURL_SSL_BACKEND="secure-transport"
' >> ~/.zshenv
Reload Changes. Type below line in terminal
source ~/.zshenv
Check if your new variable is set properly. Type below line in terminal
echo CURL_SSL_BACKEND
Accepted answer worked, but you might have to check if the lib and include paths are correct with
brew info openssl
and
brew info curl

Curl Request TLS alert, unknown CA in Windows WSL

Running this command inside wsl 2 windows delivers the below output.
Can anyone explain why there are mixed TLSv1.3 and TLSv1.2 IN and OUT and is this a potential reason as to why its unable to get local issuer certificate.
The Windows host OS is Enterprise
I have installed ca-certificates and ran update-ca-certificates
curl -v https://google.com:443/
* Trying 172.217.169.78...
* TCP_NODELAY set
* Connected to google.com (172.217.169.78) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* 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.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
Are you using a network connection subject to monitoring or 'protection' such as antivirus, like one provided by a business, organization or school? If so you are probably getting a fake cert/chain from the interceptor.
Try openssl s_client -connect google.com:443 and look at the s:and i: lines under Certificate chain. (Many hosts today require SNI to respond correctly and if your OpenSSL is below 1.1.1 you need to add -servername x to provide SNI, but google is not one of them, and anyway since your curl is at least trying 1.3 it cannot be OpenSSL below 1.1.1.)
Or, if connecting from Chrome, Edge or IE (but maybe not Firefox) on the host Windows works normally, doubleclick the padlock and look at the cert chain to see if it leads to GlobalSign Root CA (as the real google does) or something else (like e.g. BlueCoat); if the latter the interceptor's root cert is installed in your host Windows store, but not the WSL system. You can export the cert from the host browser and put it in a file, and either use it manually with curl --cacert $file, or import it to the WSL system's truststore, but that depends on what system you are running in WSL which you didn't say.
Added: the mixture of TLS 1.3 and 1.2 in the logging info is probably because 1.3 uses the same record header version as 1.2 as a transition hack, with an extension that indicates it is really 1.3 only in the two Hello messages, and the callback probably doesn't deal with this.
Turns out there were missing certificates that once provided and installed it worked fine

curl: (60) SSL certificate problem: when uploading behind proxy

I need to do curl uploading behind company proxy. and I've getting the following two type of problems depending on the site that I try,
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
curl: (60) SSL certificate problem: unable to get local issuer certificate
Here are the details:
Case 1:
. . .
< HTTP/1.1 200 Connection established
< Proxy-agent: CCProxy
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CONNECT phase completed!
* CONNECT phase completed!
* error:1408F10B:SSL routines:ssl3_get_record:wrong version number
* Closing connection 0
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
Case 2:
$ curl -vX POST -d "userId=5&title=Hello World&body=Post body." https://jsonplaceholder.typicode.com/posts
Note: Unnecessary use of -X or --request, POST is already inferred.
* Uses proxy env variable https_proxy == 'http://10.xx.xx.xx:808/'
* Trying 10.xx.xx.xx:808...
* TCP_NODELAY set
* Connected to 10.xx.xx.xx port 808 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to jsonplaceholder.typicode.com:443
> CONNECT jsonplaceholder.typicode.com:443 HTTP/1.1
> Host: jsonplaceholder.typicode.com:443
> User-Agent: curl/7.68.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
< Proxy-agent: CCProxy
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CONNECT phase completed!
* CONNECT phase completed!
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
The problem is not the above CCProxy, but our company is using the Zscaler transparent proxy which is intercepting SSL requests with its own certificate.
Is there any way to fix it pls?
$ curl --version
curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1g zlib/1.2.11 brotli/1.0.7 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.8.0 nghttp2/1.40.0 librtmp/2.3
Release-Date: 2020-01-08
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux bullseye/sid
Release: testing
Codename: bullseye
Step 1 in both options will extract the Zscaler certificates.
OPTION 1 Direct curl
Download the certificates (all certificates are included in a single file)
Execute the curl command passing the certificateS you want to use.
# 1
openssl s_client -showcerts \
-connect jsonplaceholder.typicode.com:443 </dev/null 2>/dev/null \
| sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' > typicode.crt
# 2
curl --cacert typicode.crt -v \
-d "userId=5&title=Hello World&body=Post body." \
https://jsonplaceholder.typicode.com/posts
OPTION 2 (installer script)
In case the curl command is executed by an installer you don't have control, then, update your certificates:
Extract the certificates from server (use the FQDN or IP and PORT, i.e: jsonplaceholder.typicode.com:443)
Move the XXX.crt certificate to your certificates directory
Update certificates
Execute installation script
# 1
openssl s_client -showcerts \
-connect jsonplaceholder.typicode.com:443 </dev/null 2>/dev/null \
| sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' > typicode.crt
# 2
sudo mv typicode.crt /usr/local/share/ca-certificates/
# 3
sudo update-ca-certificates
# 4 execute your installer script
Bonus
In case you need/want to get the Zscaler certificates only, get the IP from: https://ip.zscaler.com
openssl s_client -showcerts -servername server -connect 165.225.216.33:443 > </dev/null 2>/dev/null | sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' | grep -m1 -B-1 -- '-----END CERTIFICATE-----' > zscaler.crt
UPDATED (11/19/21):
Adding option 1, when is a direct curl and no need of install the certificates.
Optimized the command for extracting the certificates (creating the file)
Bonus: Getting the Zscaler IP
Tested on Ubuntu 20 and 18 behind Zscaler proxy.
Without certificate
With certificate
References:
How to install certificates for command line
unable to connect to server: x509: certificate signed by unknown authority
The answer is to "add that proxy's certificate to the CA bundle", thanks to Daniel Stenberg's answer. Then I guess I am suppose to fill in the rest. So here it is my attempt solving the remaining of the problems/questions --
Q: What is the easiest way to get that Zscaler certificate?
A: From here:
Go to Policy > SSL Inspection. In the Intermediate Root Certificate Authority for SSL Interception section, click Download Zscaler Root Certificate. Navigate to the ZscalerRootCerts. zip file and unzip it.
Q: How to add that certificate to the CA bundle?
A: See How to install company proxy certificate:
You can use curl --cacert <CA certificate> to supply your company CA cert.
Or you can add your company CA cert to /etc/pki/tls/certs/ and run make there to make it available system-wide.
This error (SSL certificate problem) means that the CA store that curl uses to verify the server's peer did not contain the cert and therefore the server couldn't be verified.
If want curl to work with a transparent proxy that terminates TLS you must add that proxy's certificate to the CA bundle or completely ignore the certificate check (which I recommend against).
A transparent proxy for TLS will of course make the connection completely unreliable and have broken security properties.

curl error despite --insecure and w/o proxy: ssl3_get_record:wrong version number

I'm using git-ftp for deployment of some sites, and with one server I don't manage to establish a connection through TLS.
curl -vv --insecure ftps://linux12.unixserver.org:21
* Rebuilt URL to: ftps://linux12.unixserver.org:21/
* Trying 212.63.145.118...
* TCP_NODELAY set
* Connected to linux12.unixserver.org (212.63.145.118) port 21 (#0)
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* error:1408F10B:SSL routines:ssl3_get_record:wrong version number
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
I already found several other questions, but my issue doesn't match.
I'm not using a proxy
Even --insecure will fail, so it can't be a cert trust issue
I tried --cacert as well, doesn't work
--tls-max 1.2 will change version to 1.2, but it doesn't change anything
Some source states that this error also occurs when the server doesn't deliver a cert at all.
openssl s_client -connect linux12.unixserver.org:21 -starttls ftp
Delivers a certificate, so that seems to be alright.
I can successfully connect by means of Nautilus, but it's warning me about the certificate, that the issuer is unknown.
Thanks very much for any hint on what else to try.
Actually two issues were involved in this case.
1) ftps is the wrong protocol for servers that only support explicit tls.
The right protocol would be ftpes. If curl is not compiled with support for it, you can use --ssl-reqd to enforce TLS, or just --ssl.
In context of git-ftp it works even if curl is compiled w/o ftpes.
2) The server didn't deliver a valid certificate chain, so the certificate could not be validated.
This is currently a ftp certificate bug in plesk.
The solution is to retrieve the certificate chain manually and provide the chain by means of --cacert <file>. If it's self-signed, extract the public key and use --pinnedpubkey <file>.
Thanks very much to Daniel Stenberg for the right hints.

SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

I have a problem, i made a command "openssl s_client -connect server.server:143", and the error is:
CONNECTED(00000003)
140719622096768:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown proto col:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 249 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
I made that because the horde connection gives an error in login.
How can i resolve this?
openssl s_client -connect server.server:143
Port 143 is plain IMAP, that is you can not talk directly TLS to this port. If you try it you will get some data back which are not TLS, and thus strange error messages will occure. If you want to have TLS you have to either use imaps (port 993) or issue a STARTTLS command. You can also use openssl for this with
openssl s_client -connect server:143 -starttls imap
From your output it might even be that you used this option but did not put it into your question (because 7 bytes from the server would match a TLS alert, but is unusually short for an IMAP greeting). If this is the case there might be lots of reasons why the connection fails and it is not possible to pin the problem down just from your description. If you get more help look at http://noxxi.de/howto/ssl-debugging.html#hdr2.2 on how you could narrow down the problem and what you should provide on information if you need help from others.