LINUX.ORG.RU
решено ФорумAdmin

openssl s_client получает неверный серт от Nginx

 ,


0

2

На серваках есть скрипт, который получает дату истечения сертов доменов для заббикса. Получение даты:

echo | openssl s_client -connect $SERVER:443 -servername $SERVER -tlsextdebug 2>/dev/null | openssl x509 -noout -dates 2>/dev/null | grep notAfter

В nginx есть дефолтная секция для виртуальных хостов, для которых нет конфигов:

server {
	listen 80 default_server;
	listen [::]:80 default_server;
	listen 443 ssl default_server;
	listen [::]:443 ssl default_server;
	server_name _;
	ssl_stapling off;
	ssl_stapling_verify off;
	ssl_certificate /etc/nginx/ssl/default.crt;
	ssl_certificate_key /etc/nginx/ssl/default.key;
	deny all;
}

На некоторых серваках и не на всех доменах вместо получения серта нужного виртуального хоста берется самоподписанный серт из этой секции, а не из конфига хоста. А если чекнуть серт того же домена с другого сервака, то все ок. С чем связано и как можно пофиксить?

★★★

Последнее исправление: zevilz (всего исправлений: 1)

Возможно ты устанвливаешь соединение по SSL (вместо TLS), либо клиент или сервер не поддерживают SNI

Хотя более вероятно, что ты в конфиге что-то не заметил. Ну и дебаг посмотри, зачем сразу фильтровать

router ★★★★★
()
Ответ на: комментарий от router

косяк начался только недавно. конфигурации всех серваков идентичные. скрипт и пакетные базы ос одинаковые везде. неверно подтягивается только серт одного домена из всех доменов на серваке. они же указаны как hostname серваков. и эта проблема только на нескольких серваках

Ну и дебаг посмотри, зачем сразу фильтровать

смотрю, но там для меня ничего полезного. вижу только то, что подтягивается дефолтный самоподписанный серт

zevilz ★★★
() автор топика
Ответ на: комментарий от router
CONNECTED(00000003)
TLS server extension "supported versions" (id=43), len=2
0000 - 03 04                                             ..
TLS server extension "key share" (id=51), len=2
0000 - 00 18                                             ..
TLS server extension "supported versions" (id=43), len=2
0000 - 03 04                                             ..
TLS server extension "key share" (id=51), len=101
0000 - 00 18 00 61 04 65 bf 8d-52 1d e9 78 48 f5 48 08   ...a.e..R..xH.H.
0010 - b3 bf 42 ae 09 cc 26 67-bc b7 47 04 27 6a c4 6f   ..B...&g..G.'j.o
0020 - 70 58 69 ff af 1b 49 a3-cc 14 3f 97 99 61 81 4a   pXi...I...?..a.J
0030 - f3 c3 9b 78 c7 58 e6 c2-74 d9 4a 91 c7 52 24 90   ...x.X..t.J..R$.
0040 - 62 ac cb 1e 72 9b ce 01-d3 d4 fa c0 7b 19 71 d5   b...r.......{.q.
0050 - 12 fe 62 23 6c 09 25 8b-af 6d 49 88 68 07 6c 08   ..b#l.%..mI.h.l.
0060 - ab a7 5f c1 d9                                    .._..
TLS server extension "server name" (id=0), len=0
depth=0 C = RU, ST = MSK, L = Uryupinsk, O = hostname.com, OU = hostname.com, CN = hostname.com
verify error:num=18:self signed certificate
verify return:1
depth=0 C = RU, ST = MSK, L = Uryupinsk, O = hostname.com, OU = hostname.com, CN = hostname.com
verify return:1
---
Certificate chain
 0 s:C = RU, ST = MSK, L = Uryupinsk, O = hostname.com, OU = hostname.com, CN = hostname.com
   i:C = RU, ST = MSK, L = Uryupinsk, O = hostname.com, OU = hostname.com, CN = hostname.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID6TCCAtGgAwIBAgIUCv7PSpHTCGLM9B9BTbQTi6kfPaswDQYJKoZIhvcNAQEL
...
An7z2qt3nfQmukBICy+0xWCrsiMmWl4nVmTc/+PHKodGiWLacLhOIXg3ng61
-----END CERTIFICATE-----
subject=C = RU, ST = MSK, L = Uryupinsk, O = hostname.com, OU = hostname.com, CN = hostname.com

issuer=C = RU, ST = MSK, L = Uryupinsk, O = hostname.com, OU = hostname.com, CN = hostname.com

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 1723 bytes and written 763 bytes
Verification error: self signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 16B773919154EA5848C8D0FC218BBC34819221CAE7D746C345F307098B3EEDEC
    Session-ID-ctx: 
    Resumption PSK: AD09922BBE5544B0664BFB61058D43AB242754221D852159CD6223A6F76C513F2FC19F9CAAC13DB7CFAEEF591EBCABD0
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - 2a 71 e2 62 6e f1 ea 49-3b c4 2f 7e 19 6d b1 cb   *q.bn..I;./~.m..
    0010 - 7e fd ce 37 80 70 4c 03-87 82 cc 6e 36 ab 9d bb   ~..7.pL....n6...

    Start Time: 1624435884
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

если сделать тот же запрос с другого сервака, то тут будет инфа о реальном серте домена

zevilz ★★★
() автор топика
Последнее исправление: zevilz (всего исправлений: 2)
Ответ на: комментарий от zevilz

TLS server extension «server name» (id=0), len=0 depth=0 C = RU, ST = MSK, L = Uryupinsk, O = hostname.com, OU = hostname.com, CN = hostname.com

Ну вроде правильно, SNI используется.

Как насчёт глупых ошибок?

  • опечатка в $SERVER (-servername $SERVER)
  • соответствующий конфиг не включен в nginx
  • $SERVER (-connect $SERVER:443) ведёт не на тот хост (DNS, /etc/hosts) или 443 порт слушает что-то ещё?

В логах что интересное есть? Можно разделить access log’и по доменам и смотреть, куда попал запрос

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

в hosts ос был еще прописан ipv6 для основного домена, который указан как hostname, а в конфиге хоста в nginx слушались только ipv4. поэтому при локальном запросе уходило в дефолтный хост)

zevilz ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.