Join Log in
Score:0
cr001 avatar Server

Openssl s_client shows CONNECT_CR_SRVR_HELLO only when -servername option provided

tr flag
cr001

I have an HTTPS-enabled centOS7 server setup with GitLab/nginx, with an A record registered on a payed DNS and certificate verified by Let's Encrypt. (I will use gitlab.example.com here). The domain name has been tested to be accessible at least via ssh and plain HTTP.

With HTTPS, I can connect to the server using direct IP like https://x.x.x.x . Although the unsafe certificate error will pop up (due to domain name mismatch), if I choose to proceed despite the warning the gitlab page will show up properly.

However if I try to access using https://gitlab.example.com the error ERR_SSL_PROTOCOL_ERROR will pop up.

I have tried using openssl s_client to debug the issue and got the following results

openssl s_client -connect gitlab.example.com:443 -servername gitlab.example.com

CONNECTED(00000003)
4658671212:error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number:/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.120.1/libressl-2.8/ssl/ssl_pkt.c:386:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 0 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: 
    Start Time: 1641487269
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Interestingly, if I don't include the -servername option, there will be no error and the certificates will be acquired properly. Using direct IP with port 443 will acquire the certificates properly too.

I tried to google the error for several hours but without any success.

I also tried using curl to access and got the same error (it seems this information is less useful than the openssl s_client result, except maybe the information that the domain name is correctly mapped to the IP address)

curl --insecure -Lv https://gitlab.example.com
*   Trying x.x.x.x...
* TCP_NODELAY set
* Connected to gitlab.example.com (x.x.x.x) 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):
* error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number
* Closing connection 0
curl: (35) error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number

Nothing shows up in Gitlab's log and I think the request did not even come beyond the SSL handshake stage.

I am stuck at this point. Any help or hint on how to even proceed with this issue would be appreciated.

668
0 + 0
Patrick Mevzek avatar
cn flag
Patrick Mevzek
Did you look at your webserver logfiles (not the application Gitlab, the server answering on port 443)? You can also add `--verbose` to curl to have all the handshake details. Which openssl version you use? It may be a TLS 1.0 vs 1.1 vs 1.2 vs 1.3 problem, see its `s_client` options of `-tls1_2` etc.
0
Reply
cr001 avatar
tr flag
cr001
As far as I understand, the Gitlab log contains everything, including the nginx server. Also the "v" in the -Lv option for my curl is the shorthand of the --verbose option
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.