I have a server (Centos 7) behind a NAT and whenever I try to access a local domain configured with Let's Encrypt SSL certificate (basically it can be any not self-signed certificate) I get an error.
[root#server2 ~]# curl https://my.domain
curl: (35) SSL received a record that exceeded the maximum permissible length.
[root#server2 ~]# wget https://my.domain
--2022-03-09 12:48:15-- https://my.domain/
Resolving my.domain (my.domain)... 100.100.100,100
Connecting to my.domain (my.domain)|100.100.100.100|:443... connected.
OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Unable to establish SSL connection.
I can access via curl or wget any other https website that is not hosted on the same server.
Also, from other servers, I can access https://my.domain/ without any issue, so I experience problems only locally.
How can I debug what is wrong with this?
Related
SYSTEM INFORMATION
OS type and version CentOS Linux 7.5.1804
Webmin version [1.998]
Virtualmin version [7.1]
I installed a wildcard ssl certificate from Letsencrypt but in the browser when verifying the certificate it shows CN = “domain.com” not “*.domain.com”.
What do I need to do, what settings to enter in order to display the correct wildcard certificate?
Thanks!
The server is not properly configured. TLS works with IPv4 for both 2much.info and bauhaus.2much.info. For IPv6 though there is no address with 2much.info but there is one for bauhaus.2much.info. Only, TLS is not enabled here, it returns instead plain HTTP on port 443.
IPv6 capable clients will usually prefer IPv6 to IPv4. The attempt of using Opera without VPN might be done in a IPv4 environment, so the working IPv4 address is used. When using the VPN though other systems will access the target and these might be IPv6 enabled - in which case the access fails.
This can also be seen in a IPv6 capable environment. It is working with IPv4:
$ openssl s_client -connect bauhaus.2much.info:443 -4
...
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
But failing with IPv6
$ openssl s_client -connect bauhaus.2much.info:443 -6
CONNECTED(00000003)
140692571469632:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:332:
I've encountered a bizarre issue where SSL certificate verification is failing on one server, but nowhere else (other servers, my local computer, etc.)
I'm using https://vpnapi.io/. Both the API endpoint and the homepage have the same issue.
Command I'm running:
curl https://vpnapi.io/
The server in question is on Digital Ocean, but I've tried the same command on another Digital Ocean server, a server on another VPS provider, and my own computer. They all work.
Why is it failing on this one server? I'm not sure where to even begin looking.
Is it a problem on the server? A problem with vpnapi.io? A problem with Digital Ocean?
Note: other APIs work from this server.
Edit: Full error message below
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Edit: more info
I'm aware of the date issue as described by one answer here: Server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none (I checked the date on the system, it is correct)
OS is Ubuntu 16.04 (it works on my other Digital Ocean machine which runs Ubuntu 18.04, and on Mac)
curl version:
curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP UnixSockets
There are lot of tools change the sni in data packet. Does ssh use sni or how HTTP injector likes software change the SNI and browse the around the internet.
SNI is an extension to the TLS protocol which allows a client to specify a virtual domain during the connection handshake, as part of the ClientHello message.
SSH and TLS are different protocols and SSH does not use SNI. Changing the SNI while making an HTTPS request just requires changing the value the TLS client presents to the target server while connecting, which is, by default, the name of the host used to resolve the IP address of the TLS server; this can be done by openssl, for example, or even by manually adding an entry to your /etc/hosts, pointing a fabricated host name to a TLS server IP address and using the former to connect to the latter. In these cases, TLS clients complain about the name mismatch between the server certificate and the host name (SNI) you are using - but that can usually be turned off.
Here is how to use a fake SNI example.com while connecting to www.google.com using the openssl's -servername argument:
openssl s_client -connect www.google.com:443 -servername example.com
And here is how to perform a full HTTPS request using cURL, passing the --insecure option to stop it complaining about the certificate name mismatch as well as manually specifying the Host header (which cURL would otherwise take from the passed URL), with the --connect-to argument used to resolve our host:port fabricated pair to the real one:
curl --connect-to example.com:443:www.google.com:443 --insecure \
-H "Host: www.google.com" https://example.com/
Quite strange issue
I have mosquitto broker working with TLS
It is correctly accessible by an MQTTfx client set up for 'Enable SSL/TLS, TLSv1.2, CA certificate file'
The same ca.crt file is used by a openwrt mosquitto client issuing
# mosquitto_pub -h x.x.x.x -p 8883 --cafile /etc/mosquitto/certs/ca.crt -i 1.1.1.1 -t test -m 123 -d
it returns
Client 1.1.1.1 sending CONNECT
Error: A TLS error occurred.
At the orher end, the broker, shows
OpenSSL Error: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
OpenSSL Error: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure
Socket error on client (null), disconnecting.
What is messing me up is the fact that the MQTTfx client instead is accepted, and it's using the same certificate..!
New connection from y.y.y.y on port 8883.
New client connected from y.y.y.y as 180ce1c04c1944e1964608221efbcf0a (c1, k60).
Sending CONNACK to 180ce1c04c1944e1964608221efbcf0a (0)
Should mean that the certificate is valid and trusted... isn't it?
What's wrong then with the other client using the exact same certificate file ?!?!
...at the end using --insecure option did the job.
Means verification of the server hostname in the server certificate.
Well it works, although using this option in a production environment potentially invalidates the use of encryption.
I'm developing a program where I have a virtual development server that runs with a self signed certificate. My program uses curl to connect to the server and pull information, but needs to do so with SSL. When I try to connect I get the error "SSL certificate problem, verify that the CA cert is OK." When running firefox I can add the certificate to just firefox, but that doesn't help me with curl. How do I add the certificate for curl to recognize?
curl 7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
Ubuntu 10.04 Lucid Lynx 64bit
This is one way that worked for me:
First, get the CA cert from the development domain and save it to a file called 'logfile'. (Assumes port 443 for SSL)
openssl s_client -connect xxxxx.com:443 |tee logfile
Then, use the --cacert curl option to use the saved certificate file.
curl --cacert logfile **THE REST OF YOUR CURL COMMAND**
Source:
http://curl.haxx.se/docs/sslcerts.html
I'd copy the certificate to /usr/local/share/ca-certificates/.
Let me quote the man page for update-ca-certificates:
Furthermore all certificates with a .crt extension found below /usr/local/share/ca-certificates are also included as implicitly trusted.
Add your rootCA.pem in /usr/share/ca-certificates directory.
After that update your certificates with: update-ca-certificates --fresh command.
I just did that, and works fine.
First, in your Linux, you should add your CERTIFICATE.cert to /usr/local/share/ca-certificates/.
After that by adding --cacert CERTIFICATE.cert to your command, curl will automatically use this certificate in that request.
Exp:
curl --cacert CERTIFICATE.cert GET "URL".
Obviously, you can edit the request to have your desired request.