Здесь есть два возможных сценария, которые нам необходимо рассмотреть.
1) Промежуточный сертификат доверен верификатору
2) Промежуточный сертификат не является доверенным верификатором
В первом случае промежуточный сертификат находится в доверенном хранилище для верификатора. Самый простой способ добиться этого - объединить корневые и вложенные файлы вместе:
$ cat testeroot.cer testesub.cer >testerootandsub.cer
Далее мы проверяем так:
$ openssl verify -CAfile testerootandsub.cer testeapp.cer
К сожалению, когда я пытаюсь это сделать, я получаю несколько ошибок:
CN = ecc-crypto-services-encipherment_UC6-InMemory, OU = ApplePay, O = Apple Inc., C = US
error 34 at 0 depth lookup: unhandled critical extension
CN = ecc-crypto-services-encipherment_UC6-InMemory, OU = ApplePay, O = Apple Inc., C = US
error 10 at 0 depth lookup: certificate has expired
error testeapp.cer: verification failed
Таким образом, первое является «необработанным критическим расширением», а второе - «срок действия сертификата истек». Давайте посмотрим на сертификат:
$ openssl x509 -in testeapp.cer -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1364869047620188509 (0x12f0fd2adc53b95d)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN = Test Apple Worldwide Developers Relations CA - ECC, OU = Certification Authority, O = Apple Inc., C = US
Validity
Not Before: May 20 04:15:57 2017 GMT
Not After : Jun 19 04:15:57 2019 GMT
Subject: CN = ecc-crypto-services-encipherment_UC6-InMemory, OU = ApplePay, O = Apple Inc., C = US
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:2e:3e:5c:cf:6b:9a:b0:4b:e7:a2:2f:3f:ac:cf:
de:73:c8:7e:87:15:53:94:a3:48:15:40:8a:89:6c:
a1:8a:37:4d:ac:66:9a:f3:bf:62:20:fc:86:37:67:
f4:af:47:50:7c:5b:c2:21:fc:4a:19:87:4d:af:39:
b4:07:4e:3e:b8
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
Authority Information Access:
OCSP - URI:http://ocsp-uat.corp.apple.com/ocsp04-testwwdrcaecc
X509v3 Subject Key Identifier:
AD:2E:A3:CB:7E:34:C2:ED:EE:43:68:4E:27:11:1F:CC:49:33:39:D0
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Authority Key Identifier:
keyid:D6:D6:D5:5A:E5:FF:FD:C2:7C:34:C3:43:DE:BD:68:76:5C:36:A9:BE
X509v3 Certificate Policies:
Policy: 1.2.840.113635.100.5.1
User Notice:
Explicit Text: Reliance on this certificate by any party assumes acceptance of the then applicable standard terms and conditions of use, certificate policy and certification practice statements.
CPS: http://www.apple.com/certificateauthority/
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl-uat.corp.apple.com/applewwdrcaecc.crl
X509v3 Key Usage: critical
Key Encipherment, Key Agreement
1.2.840.113635.100.6.39: critical
..
Signature Algorithm: ecdsa-with-SHA256
30:46:02:21:00:8c:bd:4a:b6:61:4c:58:fd:1a:93:58:4e:05:
aa:c3:d3:af:dc:c6:ca:29:42:ba:72:14:dc:54:a8:6e:d7:a9:
ee:02:21:00:de:d5:77:1d:c1:d2:9e:c3:4c:2a:97:1d:dd:39:
20:fb:19:18:b7:48:0c:6d:4d:4f:13:a4:d8:e8:ff:37:b1:86
Сначала мы увидим, что срок действия сертификата действительно истек («Не после» означает «19 июня 04:15:57 2019 по Гринвичу»). Во-вторых, есть критическое расширение, которое OpenSSL не распознает:
1.2.840.113635.100.6.39: critical
..
Мы можем заставить OpenSSL игнорировать эти две ошибки, например:
$ openssl verify -ignore_critical -no_check_time -CAfile testerootandsub.cer testeapp.cer
testeapp.cer: OK
Второй сценарий, о котором я говорил, - это гдепромежуточный сертификат не является доверенным для верификатора. В этом случае предполагается, что верификатор имеет корень в своем хранилище доверенных сертификатов, и ему будут предоставлены сертификаты промежуточных и конечных объектов. В этом случае команда проверки выглядит следующим образом:
$ openssl verify -ignore_critical -no_check_time -CAfile testeroot.cer -untrusted testesub.cer testeapp.cer
testeapp.cer: OK