Errore nell'handshake SSL con un servizio Web - la catena viola il limite dei limiti di base

Naviga le tue risposte
1

Sto scrivendo un programma in cui invochiamo un servizio web SOAP di terze parti su HTTPS. Attualmente sto ricevendo un errore nella fase SSL Handshake e fallisce con il seguente errore - catena viola il limite dei vincoli di base.

Il server Web sta inviando una catena di certificati come segue:
   FOGLIA - I1 - I2 - I3

Il mio codice è in grado di convalidare la catena nel modo seguente, poiché mi sono fidato di tutti i certificati incluso root:
   FOGLIA - I1 - I2 - I3 - R

Tuttavia, il problema è che il certificato intermedio I3 ha un pathLen di 1 , ma ha 2 certificati intermedi tra il certificato Leaf (End-Entity) e lo stesso I3, che sta causando il problema.

Come è stato risolto?

  1. È necessario chiedere all'host / provider del servizio Web SOAP di modificare la configurazione del certificato alla loro estremità?
  2. Inoltre, in che modo il server invia addirittura una catena che viola i vincoli?

Ulteriori informazioni:

  1. I1 (cioè CA intermedio 1) ha DN Entrust Certification Authority - L1K

    Il certificato può essere scaricato da qui: Scarica I1 ("entrust_l1k.cer") dal sito Entrust

  2. I2 (cioè CA intermedio 2) ha DN CN=Entrust Root Certification Authority - G2, OU="(c) 2009 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US

    Il numero di serie del certificato è 4a538c28 e il certificato può essere scaricato da qui: Scarica I2 ("entrust_g2_ca.cer") da Affida il sito

    È interessante notare che questo certificato ha lo stesso DN ed emittente, ma non viene trattato come certificato di origine probabilmente perché non ha identificatore chiave di autorizzazione = identificatore chiave soggetto.

  3. I3 (cioè CA intermedio 3) ha DN CN=Entrust Root Certification Authority - G2, OU="(c) 2009 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US

    Il certificato I3 ha lo stesso DN di I2 ed è l'emittente di I2, ma I3 stesso è emesso da un'autorità diversa, cioè CA radice, e ha un numero di serie 51d34044 . Questo certificato ha anche pathLen di 1 .

    Non riesco a trovare questo certificato sul sito di fiducia, quindi sto incollando il contenuto qui. 

    -----BEGIN CERTIFICATE-----
MIIE/zCCA+egAwIBAgIEUdNARDANBgkqhkiG9w0BAQsFADCBsDELMAkGA1UEBhMC
VVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0
Lm5ldC9DUFMgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMW
KGMpIDIwMDYgRW50cnVzdCwgSW5jLjEtMCsGA1UEAxMkRW50cnVzdCBSb290IENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE0MDkyMjE3MTQ1N1oXDTI0MDkyMzAx
MzE1M1owgb4xCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgw
JgYDVQQLEx9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQL
EzAoYykgMjAwOSBFbnRydXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9u
bHkxMjAwBgNVBAMTKUVudHJ1c3QgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuoS2ctueDGvi
mekwAad26jK4lUEaydphTlhyz/72gnm/c2EGCqUn2LNf00VOHHLWTjLycooP94MZ
0GqAgABFHrDH55q/ElcnHKNoLwqHvWprDl5l8xx31dSFjXAhtLMy54ui1YY5ArG4
0kfO5MlJxDun3vtUfVe+8OhuwnmyOgtV4lCYFjITXC94VsHClLPyWuQnmp8k18bs
0JslguPMwsRFxYyXegZrKhGfqQpuSDtv29QRGUL3jwe/9VNfnD70FyzmaaxOMkxi
d+q36OW7NLwZi66cUee3frVTsTMi5W3PcDwa+uKbZ7aD9I2lr2JMTeBYrGQ0EgP4
to2UYySkcQIDAQABo4IBDzCCAQswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI
MAYBAf8CAQEwMwYIKwYBBQUHAQEEJzAlMCMGCCsGAQUFBzABhhdodHRwOi8vb2Nz
cC5lbnRydXN0Lm5ldDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmVudHJ1
c3QubmV0L3Jvb3RjYTEuY3JsMDsGA1UdIAQ0MDIwMAYEVR0gADAoMCYGCCsGAQUF
BwIBFhpodHRwOi8vd3d3LmVudHJ1c3QubmV0L0NQUzAdBgNVHQ4EFgQUanImetAe
733nO2lR1GyNn5ASZqswHwYDVR0jBBgwFoAUaJDkZ6SmU4DHhmak8fdLQ/uEvW0w
DQYJKoZIhvcNAQELBQADggEBAGkzg/woem99751V68U+ep11s8zDODbZNKIoaBjq
HmnTvefQd9q4AINOSs9v0fHBIj905PeYSZ6btp7h25h3LVY0sag82f3Azce/BQPU
AsXx5cbaCKUTx2IjEdFhMB1ghEXveajGJpOkt800uGnFE/aRs8lFc3a2kvZ2Clvh
A0e36SlMkTIjN0qcNdh4/R0f5IOJJICtt/nP5F2l1HHEhVtwH9s/HAHrGkUmMRTM
Zb9n3srMM2XlQZHXN75BGpad5oqXnafOrE6aPb0BoGrZTyIAi0TVaWJ7LuvMuueS
fWlnPfy4fN5Bh9Bp6roKGHoalUOzeXEodm2h+1dK7E3IDhA=
-----END CERTIFICATE-----

  4. R (cioè certificato root) ha DN CN=Entrust Root Certification Authority, OU="(c) 2006 Entrust, Inc.", OU=www.entrust.net/CPS is incorporated by reference, O="Entrust, Inc.", C=US .

    Questo certificato ha il numero di serie ‎45 6b 50 54 e può essere scaricato da qui: Scarica R ("entrust_ev_ca.cer") da Affida il sito

Ulteriori informazioni

  • i1 

    $ openssl x509 -noout -fingerprint -in entrust_l1k.cer
SHA1 Fingerprint=F2:1C:12:F4:6C:DB:6B:2E:16:F0:9F:94:19:CD:FF:32:84:37:B2:D7

    Link Crt.sh

  • i2 

    $ openssl x509 -noout -fingerprint -in entrust_g2_ca.cer
SHA1 Fingerprint=8C:F4:27:FD:79:0C:3A:D1:66:06:8D:E8:1E:57:EF:BB:93:22:72:D4

    Link Crt.sh

  • i3 

    $ openssl x509 -noout -fingerprint -in i3.cer
SHA1 Fingerprint=9E:1A:0C:35:E7:14:B6:97:92:D0:90:B2:CC:4B:BA:45:83:3C:30:15

    Link Crt.sh

  • R 

    $ openssl x509 -noout -fingerprint -in R.cer
SHA1 Fingerprint=B3:1E:B1:B7:40:E3:6C:84:02:DA:DC:37:D4:4D:F5:D4:67:49:52:F9

    Link Crt.sh

posta abhishek 27.07.2018 - 10:16
fonte

2 risposte

3

I3 è "link cert", pensato per il bridge su un rollover della Root CA. La prova: 

 X509v3 Subject Key Identifier:
     6A:72:26:7A:D0:1E:EF:7D:E7:3B:69:51:D4:6C:8D:9F:90:12:66:AB
 X509v3 Authority Key Identifier:
     keyid:68:90:E4:67:A4:A6:53:80:C7:86:66:A4:F1:F7:4B:43:FB:84:BD:6

Questi corrispondono agli identificatori chiave oggetto del tuo I2 e R rispettivamente. Per i clienti che sono a conoscenza dei certificati di collegamento, dice "Ciao, sono root cert 68: 90: E4: .. e diventerò il cert root 6A: 72: 26: ..". Pittoricamente: 

LEAF <-- I1 <-- Rnew <-- link_Rold_to_Rnew <-- Rold

Come fai notare, I2 è un certificato radice valido, quindi i vincoli di base di pathLen vanno bene qui. Chiaramente, qualunque client tu stia usando per validare la catena di certificati non comprende i certs di collegamento.

Penso ci siano due opzioni:

  1. Scopri perché il tuo client non comprende i certs di collegamento e risolvilo.
  2. Chiedere al maintainer del servizio Web SOAP di interrompere la pubblicazione di tutti e 5 i certificati e solo di servire. LEAF <-- I1 <-- Rnew .

Anche se ho il sospetto che lo abbiano fatto perché alcuni altri clienti hanno Rold solo nel loro negozio di fiducia e hanno bisogno che il certificato di collegamento sia lì.

    
risposta data 27.07.2018 - 14:49
fonte
0

Fidati dei prodotti intermedi?

Hai scritto:

as I have trusted all the certificates including root

Questo sembra sbagliato. Di solito non ti fidi esplicitamente di prodotti intermedi. (Puoi tuttavia ESTRARRE esplicitamente in DISTRIBUZIONE se vengono compromessi). Perché eseguire una verifica / costruzione di una catena del tutto se poi puoi finire al primo passaggio intermedio?

Mixup con intermedio? È stata inviata una catena errata?

Ho aggiunto alcuni link a crt.sh alla tua domanda. E sembra che quello che tu chiami "i2" non sia affatto un cert intermedio, ma un certificato radice. È un errore? = > Vedi crt.sh

Hai scritto che non è "trattato come certificato di origine" . Come puoi dirlo? - Penso che la catena che viene inviata sia semplicemente sbagliata / non all'altezza delle specifiche.

= > Prova a controllare con link - Questo ti avviserà sulle irregolarità della catena.

Inoltre: ho trovato questo: secondo RFC 5280 che non ha Authority Key identifier è consentito per le radici: 

The keyIdentifier field of the authorityKeyIdentifier extension MUST
be included in all certificates generated by conforming CAs to
facilitate certification path construction.  There is one exception;
where a CA distributes its public key in the form of a "self-signed"
certificate, the authority key identifier MAY be omitted.
    
risposta data 28.07.2018 - 18:51
fonte

Leggi altre domande sui tag

È necessario aggiungere CSP a tutte le pagine Web in un'applicazione Web? Come configurare più di uno stesso Hardware Security Module (HSM)