Puncte:0

Este posibil să se verifice TLS dacă un server nu oferă un certificat emitent?

drapel kz

Încerc să configurez Apache httpd v2.4 pentru autentificarea LDAP la AD. Certificatele LDAPS sunt emise de CA intern. Indiferent de motiv (nu fac parte din echipa AD), nici mediile noastre prod sau non-prod nu publică întregul lanț.

Non-prod trimite serverul și certificatele intermediare, dar nu și rădăcina. Mă pot conecta cu succes prin Apache cu:

LDAPVerifyServerCert Activat
LDAPTrustedGlobalCert CA_BASE64 chain.crt
# $cat intermediate.pem root.pem > chain.crt

Din păcate, prod trimite doar certificatul serverului. Fără intermediar (emitent) și fără rădăcină. Furnizarea aceluiași lanț care conține emitentul și rădăcina nu funcționează. Am încercat tot ce mi se poate gândi: server cert only, int only, server + int, server + int + root, dar nimic nu funcționează, fie în Apache, fie testând cu openssl s_client -connect $x -CAfile $y.

Evident, cea mai bună opțiune este ca echipa AD să publice întregul lanț, dar există vreo altă modalitate de a verifica conexiunea (altul decât dezactivarea verificării)?

Editați | ×:

Aici este rezultatul lui openssl s_client -connect devldap.company.com:636 -CAfile int+root.pem:

CONECTAT(00000003)
adâncime=2 CN = Rădăcina companiei CA
verifica returnarea:1
adâncime=1 DC = com, DC = companie CN = Companie Intermediar CA
verifica returnarea:1
adâncime=0 C = SUA, ST = Stat, O = Companie, OU = OTS, CN = devldap.company.com
verifica returnarea:1
---
Lanț de certificate
 0 s:C = SUA, ST = Stat, O = Companie, OU = OTS, CN = devldap.company.com
   i:DC = com, DC = firma CN = Company Intermediate CA
 1 s:DC = com, DC = firma CN = Company Intermediate CA
   i:CN = Company Root CA
---
Certificat de server
-----ÎNCEPE CERTIFICAT-----
MIIH8TCCBtmgAwIBAgITTQACdEm5xkCMTnqGDQAAAAJ0STANBgkqhkiG9w0BAQsF
...
jce8VpEUyZKDClUrcyRBSxd0rq2I
-----CERTIFICAT FINAL-----
subiect=C = SUA, ST = Stat, O = Companie, OU = OTS, CN = devldap.company.com

emitent=DC = com, DC = companie CN = Company Intermediate CA

---
Nu s-au trimis nume de CA de certificat de client
Tipuri de certificat de client: semn RSA, semn DSA, semn ECDSA
Algoritmi de semnătură solicitați: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
Algoritmi de semnătură solicitați partajați: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:RSA+SHA512:ECDSA+SHA512
Rezumat peer signing: SHA256
Tip semnătură peer: RSA
Cheie Temp Server: ECDH, P-384, 384 biți
---
SSL handshake a citit 4639 de octeți și a scris 486 de octeți
Verificare: OK
---
Nou, TLSv1.2, Cipher este ECDHE-RSA-AES256-GCM-SHA384
Cheia publică a serverului este de 2048 biți
Este acceptată renegocierea sigură
Compresie: NIMIC
Extindere: NIMIC
Nu s-a negociat ALPN
Sesiune SSL:
    Protocol: TLSv1.2
    Cifr: ECDHE-RSA-AES256-GCM-SHA384
    ID sesiune: F90...411
    ID-ul sesiunii-ctx: 
    Cheie principală: 985...D1E
    Identitate PSK: Niciuna
    Sugestie de identitate PSK: Niciuna
    Nume de utilizator SRP: niciunul
    Ora de începere: 1651420792
    Timeout: 7200 (sec)
    Verificați codul de returnare: 0 (ok)
    Secret principal extins: da
---
TERMINAT

Și pentru prod, openssl s_client -connect ldap.company.com:636 -CAfile int+root.pem:

CONECTAT(00000003)
adâncime=0 C = SUA, ST = Stat, O = Companie, CN = ldap.company.com
verify error:num=20:nu se poate obține certificatul de emitent local
verifica returnarea:1
adâncime=0 C = SUA, ST = Stat, O = Companie, CN = ldap.company.com
verify error:num=21:nu se poate verifica primul certificat
verifica returnarea:1
adâncime=0 C = SUA, ST = Stat, O = Companie, CN = ldap.company.com
verifica returnarea:1
---
Lanț de certificate
 0 s:C = SUA, ST = Stat, O = Companie, CN = ldap.company.com
   i:DC = com, DC = firma CN = Company Intermediate CA
---
Certificat de server
-----ÎNCEPE CERTIFICAT-----
MIIHXzCCBkegAwIBAgITTQADO1BEj8rlaKH+eQAAAAM7UDANBgkqhkiG9w0BAQsF
...
FGBKggzc3AK2pcHT9E3f46Oy+A==
-----CERTIFICAT FINAL-----
subiect=C = SUA, ST = Stat, O = Companie, CN = ldap.company.com

emitent=DC = com, DC = companie CN = Company Intermediate CA

---
Nu s-au trimis nume de CA de certificat de client
---
SSL handshake a citit 2059 de octeți și a scris 655 de octeți
Eroare de verificare: nu se poate verifica primul certificat
---
Nou, SSLv3, Cipher este AES256-SHA
Cheia publică a serverului este de 2048 biți
Renegocierea sigură NU ESTE acceptată
Compresie: NIMIC
Extindere: NIMIC
Nu s-a negociat ALPN
Sesiune SSL:
    Protocol: TLSv1.2
    Cifrare: AES256-SHA
    ID sesiune: 33B...377
    ID-ul sesiunii-ctx: 
    Cheie principală: A5D...ACE
    Identitate PSK: Niciuna
    Sugestie de identitate PSK: Niciuna
    Nume de utilizator SRP: niciunul
    Ora de începere: 1651420815
    Timeout: 7200 (sec)
    Verificați codul de returnare: 21 (nu se poate verifica primul certificat)
    Secret principal extins: nu
---
TERMINAT

Editați | ×: Se pare că fișierul numit „int.pem” a fost de fapt un certificat de server dintr-un proiect diferit. Neato. Mi-ar fi plăcut să fi verificat asta înainte de a pierde atât de mult timp cu asta. Cu un lanț care conține certificatul și rădăcina CA intermediară reală, se verifică cu succes.

dave_thompson_085 avatar
drapel jp
Serverele TLS sunt permise (și uneori încurajate) să omite certificatul rădăcină; cazul dvs. non-prod este normal și ar trebui să funcționeze cu (doar) root în `LDAPTrustedGlobalCert CA*`. OpenSSL în mod implicit poate completa lanțul din truststore și `openssl s_client -connect $prod:636 -CAfile int_and_root.pem` (dacă openssl sub 1.1.1 _and_ serverul vrea SNI pe care nu-l cunosc pentru MS, adăugați `- servername $prod`) ar trebui să funcționeze; daca nu, poti da detalii? Dar, în timp ce Apache folosește OpenSSL pentru https, nu îmi este clar dacă (sau cum) folosește OpenSSL pentru ldaps, așa că s-ar putea să nu ajute.
Joe Buckley avatar
drapel kz
@dave_thompson_085 Am adăugat ieșirea s_client la postare. V-ar deranja să aruncați o altă privire?
Joe Buckley avatar
drapel kz
@dave_thompson_085 Mulțumesc mult! Din păcate, a fost o eroare de utilizator din partea mea. Cumva, ceea ce am jurat a fost că certificatul intermediar era de fapt un certificat de server pentru cu totul altceva. S-a creat un nou .pem cu rădăcina int + reală și verifică și funcționează și în Apache.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.