Điểm:0

Openssl s_client shows CONNECT_CR_SRVR_HELLO only when -servername option provided

lá cờ tr

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.

Patrick Mevzek avatar
lá cờ cn
Bạn đã xem tệp nhật ký máy chủ web của mình chưa (không phải ứng dụng Gitlab, máy chủ trả lời trên cổng 443)? Bạn cũng có thể thêm `--verbose` vào cuộn tròn để có tất cả các chi tiết bắt tay. Phiên bản openssl nào bạn sử dụng? Đó có thể là sự cố TLS 1.0 so với 1.1 so với 1.2 so với 1.3, hãy xem các tùy chọn `s_client` của `-tls1_2`, v.v.
cr001 avatar
lá cờ tr
Theo như tôi hiểu, nhật ký Gitlab chứa mọi thứ, kể cả máy chủ nginx. Ngoài ra, "v" trong tùy chọn -Lv cho curl của tôi là cách viết tắt của tùy chọn --verbose

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.