Error en el protocolo de enlace SSL con un servicio web: la cadena viola el límite de restricciones básicas

1

Estoy escribiendo un programa en el que invocamos un servicio web SOAP de terceros a través de HTTPS. Actualmente recibo un error en la etapa de protocolo de enlace de SSL y falla con el siguiente error: la cadena viola el límite de restricciones básicas.

El servidor web está enviando una cadena de certificados de la siguiente manera:
   HOJA - I1 - I2 - I3

Mi código puede validar la cadena de la siguiente manera, ya que confié en todos los certificados, incluida la raíz:
   HOJA - I1 - I2 - I3 - R

Sin embargo, el problema es que el Certificado Intermedio I3 tiene un pathLen de 1 , pero tiene 2 de certificados intermedios entre el certificado Leaf (End-Entity) y el propio I3, lo que está causando el problema.

¿Cómo podría resolverse esto?

  1. ¿Debemos pedirle al proveedor / proveedor de servicios web SOAP que cambie la configuración del certificado en su extremo?
  2. Además, ¿cómo está el servidor incluso enviando una cadena que viola las restricciones?

Más información:

  1. I1 (es decir, el CA intermedio 1) tiene DN Entrust Certification Authority - L1K

    El certificado se puede descargar desde aquí: Descargue I1 ("entrust_l1k.cer") desde Entrust Site

  2. I2 (es decir, CA intermedia 2) tiene 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

    El número de serie del certificado es 4a538c28 y el certificado se puede descargar desde aquí: Descargue I2 ("entrust_g2_ca.cer") desde Confíe en el sitio

    Es interesante que este certificado tiene el mismo DN y el mismo Emisor, pero probablemente no se trata como un certificado raíz porque probablemente no tiene el Identificador de clave de autorización = Identificador de clave del sujeto.

  3. I3 (es decir, CA intermedia 3) tiene 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

    El certificado I3 tiene el mismo DN que I2 y es el emisor de I2, pero I3 es emitido por una autoridad diferente, es decir, CA raíz, y tiene un número de serie 51d34044 . Este certificado también tiene pathLen de 1 .

    No puedo encontrar este certificado en el sitio de confianza, por lo que estoy pegando el contenido aquí.

    -----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 (es decir, el certificado raíz) tiene 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 .

    Este certificado tiene el número de serie ‎45 6b 50 54 y se puede descargar desde aquí: Descargue R ("entrust_ev_ca.cer") desde Confíe en el sitio

Más información

  • 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
    

    Crt.sh link

  • 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
    

    Crt.sh link

  • 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
    

    Crt.sh link

  • 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
    

    Crt.sh link

pregunta abhishek 27.07.2018 - 10:16
fuente

2 respuestas

3

I3 es "link cert", destinado a crear un puente sobre una transferencia de CA raíz. Evidencia:

 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

Esos coinciden con los identificadores clave de asunto de su I2 y R respectivamente. Para los clientes que conocen los certificados de enlace, dice "Hola, soy root cert 68: 90: E4: .. y me convertiré en root cert 6A: 72: 26: ..". Pictóricamente:

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

Como señala, I2 es un certificado raíz válido, por lo que las restricciones básicas de pathLen están bien aquí. Claramente, cualquier cliente que esté utilizando para validar la cadena de certificados no comprende los certificados de enlace.

Creo que hay dos opciones:

  1. Averigüe por qué su cliente no entiende los certificados de enlace y corríjalo.
  2. Pida al mantenedor del servicio web SOAP que deje de entregar los 5 certificados y que solo lo haga. LEAF <-- I1 <-- Rnew .

Aunque sospecho que lo han hecho porque algún otro cliente solo tiene a Rold en su tienda de confianza y necesita el certificado de enlace para estar allí.

    
respondido por el Mike Ounsworth 27.07.2018 - 14:49
fuente
0

¿Confía en intermediarios?

Usted escribió:

  

ya que he confiado en todos los certificados, incluida la raíz

Eso suena mal. Normalmente no confías explícitamente en intermediarios. (Sin embargo, podría ponerles en CONFIANZA explícitamente si se ven comprometidos). ¿Por qué realizar una construcción / verificación de la cadena si puede terminar en el primer intermedio de la cadena?

¿Mezcla con intermedio? ¿Solo cadena equivocada enviada?

He agregado algunos enlaces a crt.sh a tu pregunta. Y parece que lo que llamas "i2" no es un certificado intermedio, sino un certificado raíz. ¿Es esto un error? = > Consulte crt.sh

Usted escribió que no es "tratado como un certificado raíz" . ¿Cómo puedes saberlo? - Creo que la cadena que se está enviando está mal / no está a la altura de las especificaciones.

= > Intente consultar con enlace : esto alertará sobre irregularidades en la cadena.

También: busqué esto: De acuerdo con RFC 5280 que no tiene un Authority Key identifier está permitido para las raíces:

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. 
    
respondido por el StackzOfZtuff 28.07.2018 - 18:51
fuente

Lea otras preguntas en las etiquetas