РЕДАКТИРОВАТЬ: Мне очень жаль, что я вынужден сказать, что проблема волшебным образом исчезла, и я понятия не имею, почему. В ответ на один из ответов я удалил все EKU из цепочки CA, и это не сработало. Вернувшись из отпуска, я создал цепочку сертификатов по 1 за раз, т.е. RootCA->VPN
затем RootCA->IntermediateCA->VPN
и наконец, RootCA->IntermediateCA->ServerCA->VPN
и он все еще работал! Понятия не имею, почему это сработало, но я был в восторге. Просто чтобы быть абсолютно уверенным, что именно удаление EKU решило эту проблему, я вернулся и добавил случайные EKU к центрам сертификации в цепочке, и, о чудо, он все еще работает ... Это абсолютно бесит, и я прошу прощения. все люди, которые пытались помочь. Клянусь, больше ничего не изменилось и в мое отсутствие никто ничего не трогал. КОНЕЦ РЕДАКТИРОВАНИЯ
При попытке подключить клиент OpenVPN (Android или Windows 7/10) к моему тест-серверу я получаю следующую ошибку:
ПРОВЕРИТЬ ОШИБКУ: глубина = 1, ошибка = неподдерживаемый сертификат, цель: C = CA, ST = QC, L = Montreal, O = Company Inc, OU = PKI, CN = Server Certificate Authority
Я использую OpenVPN 2.3.7 на OpenBSD. Я использую следующую иерархию PKI CA, созданную с использованием XCA:
RootCA -> IntermediateCA -> ServerCA
Я создал сертификат для своего VPN-сервера, подписанный моим ServerCA. Обратите внимание на глубину = 1. Похоже, это не проблема с окончательным сертификатом VPN-сервера. OpenVPN жалуется на эмитент сертификата VPN-сервера. Даже CN в сообщении об ошибке - это ServerCA, а НЕ vpn-сервера.
Насколько мне удалось определить, ЦС в цепочке не требует, чтобы у ЦС была какая-либо другая цель, кроме подписания сертификатов.
Вот конфигурация сертификата VPN-сервера. Обратите внимание, что там есть старое расширение сервера Netscape, как того требует OpenVPN:
nsCertType=server, email
extendedKeyUsage=serverAuth, nsSGC, ipsecEndSystem, iKEIntermediate
keyUsage=digitalSignature, keyEncipherment, dataEncipherment, keyAgreement
authorityKeyIdentifier=keyid, issuer
subjectKeyIdentifier=hash
basicConstraints=CA:FALSE
Вот конфигурация сертификата выдающего CA:
crlDistributionPoints=crlDistributionPoint0_sect
extendedKeyUsage=critical,OCSPSigning
keyUsage=critical,keyCertSign, cRLSign
authorityKeyIdentifier=keyid, issuer
subjectKeyIdentifier=hash
basicConstraints=critical,CA:TRUE,pathlen:0
[crlDistributionPoint0_sect]
fullname=URI:http://pki.company.ca/server.crl
Я пробовал добавить nsCertType=server
в ServerCA, но изменений не было.
Я также видел бесконечные сообщения на форуме, где люди забывали добавить расширение nsCertType и получали ошибку, похожую на мою, но с depth=0
вместо. В моем случае сертификат сервера вроде в порядке.
Может ли кто-нибудь сказать мне, почему OpenVPN заботится о том, что разрешено делать CA в цепочке (кроме подписания сертификатов, очевидно)? Как я могу узнать, какую «цель сертификата» ожидал клиент? Как я могу заставить OpenVPN принимать цепочку сертификатов?
По запросу, вот сертификат VPN-сервера:
$ openssl x509 -noout -text -in vpn-server.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4 (0x4)
Signature Algorithm: sha512WithRSAEncryption
Issuer: C=CA, ST=QC, L=Montreal, O=Company Inc, OU=PKI, CN=Server Certificate Authority
Validity
Not Before: Jun 21 17:58:00 2016 GMT
Not After : Jun 21 17:58:00 2021 GMT
Subject: C=CA, ST=QC, L=Montreal, O=Company Inc, OU=VPN, CN=vpn.company.ca
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
**:**:**:**:**:**:**:**
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
A9:EF:EB:8B:68:E2:5F:0A:5D:FC:8A:39:7D:59:BE:21:75:2A:CB:8E
X509v3 Authority Key Identifier:
keyid:60:F3:33:2C:F7:13:09:F8:5C:3C:B2:D1:0B:9D:7D:9E:86:6A:24:41
DirName:/C=CA/ST=QC/L=Montreal/O=Company Inc/OU=PKI/CN=Intermediate Certificate Authority
serial:03
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
X509v3 Extended Key Usage:
TLS Web Server Authentication, Netscape Server Gated Crypto, IPSec End System, 1.3.6.1.5.5.8.2.2
Netscape Cert Type:
SSL Server, S/MIME
Signature Algorithm: sha512WithRSAEncryption
**:**:**:**:**:**:**:**
А вот и сертификат эмитента:
$ openssl x509 -noout -text -in server-ca.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: sha512WithRSAEncryption
Issuer: C=CA, ST=QC, L=Montreal, O=Company Inc, OU=PKI, CN= Intermediate Certificate Authority
Validity
Not Before: Jun 21 17:57:00 2016 GMT
Not After : Jun 21 17:57:00 2026 GMT
Subject: C=CA, ST=QC, L=Montreal, O=Company Inc, OU=PKI, CN= Server Certificate Authority
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
**:**:**:**:**:**:**:**
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Subject Key Identifier:
60:F3:33:2C:F7:13:09:F8:5C:3C:B2:D1:0B:9D:7D:9E:86:6A:24:41
X509v3 Authority Key Identifier:
keyid:09:26:2E:AB:F4:C1:53:E1:10:11:DE:25:2D:20:D5:76:27:A9:FF:23
DirName:/C=CA/ST=QC/L=Montreal/O=Company Inc/OU=PKI/CN=Root Certificate Authority
serial:02
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Extended Key Usage: critical
OCSP Signing
X509v3 CRL Distribution Points:
Full Name:
URI:http://pki.company.ca/server.crl
Signature Algorithm: sha512WithRSAEncryption
**:**:**:**:**:**:**:**
Хм, easyrsa OpenVPN создает такие сертификаты:
CA1:
X509v3 Subject Key Identifier:
87:13:73:D4:7C:9A:E1:EA:9A:F8:90:48:93:18:5A:B0:AF:B9:B6:25
X509v3 Authority Key Identifier:
keyid:87:13:73:D4:7C:9A:E1:EA:9A:F8:90:48:93:18:5A:B0:AF:B9:B6:25
DirName:/CN=Easy-RSA CA
serial:8B:E0:6F:16:C0:46:46:FC
X509v3 Basic Constraints:
CA:TRUE
X509v3 Key Usage:
Certificate Sign, CRL Sign
CA2:
X509v3 Basic Constraints:
CA:TRUE
X509v3 Subject Key Identifier:
D6:60:98:E7:6E:7C:73:9A:38:62:09:EC:C7:5D:62:15:89:AA:B2:8E
X509v3 Authority Key Identifier:
keyid:87:13:73:D4:7C:9A:E1:EA:9A:F8:90:48:93:18:5A:B0:AF:B9:B6:25
DirName:/CN=Easy-RSA CA
serial:8B:E0:6F:16:C0:46:46:FC
X509v3 Key Usage:
Certificate Sign, CRL Sign
Сервер:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
53:BA:B4:3B:87:AC:89:41:14:28:8F:C9:A2:F3:38:D4:43:90:EF:A6
X509v3 Authority Key Identifier:
keyid:D6:60:98:E7:6E:7C:73:9A:38:62:09:EC:C7:5D:62:15:89:AA:B2:8E
DirName:/CN=Easy-RSA CA
serial:CB:8A:25:7F:5A:8A:A9:BD:63:D2:BE:B7:6C:5E:3E:75
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
Клиент:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
F5:34:3A:39:C6:90:E0:2F:E3:92:A7:D2:0D:18:C7:48:E6:48:9F:DA
X509v3 Authority Key Identifier:
keyid:D6:60:98:E7:6E:7C:73:9A:38:62:09:EC:C7:5D:62:15:89:AA:B2:8E
DirName:/CN=Easy-RSA CA
serial:CB:8A:25:7F:5A:8A:A9:BD:63:D2:BE:B7:6C:5E:3E:75
X509v3 Key Usage:
Digital Signature
X509v3 Extended Key Usage:
TLS Web Client Authentication
Но у вас есть и эти значения Key Usage, так что ваша конфигурация должна работать ... Но промежуточного CA нет ...
Вы пытаетесь установить --ca к корневому сертификату CA и установите --extra-certs к промежуточному ЦС и --серт к сертификату сервера, чтобы сформировать полную цепочку? И не забывай - ключ слишком.
На самом деле у меня это работает:
Сервер:
Tue Jun 21 04:39:49 2016 VERIFY OK: depth=2, CN=Easy-RSA CA
Tue Jun 21 04:39:49 2016 VERIFY OK: depth=1, O=Easy-RSA CA2, CN=Easy-RSA CA2
Tue Jun 21 04:39:49 2016 VERIFY OK: depth=0, O=client, CN=client
Клиент:
Tue Jun 21 04:39:49 2016 VERIFY OK: depth=2, CN=Easy-RSA CA
Tue Jun 21 04:39:49 2016 VERIFY OK: depth=1, O=Easy-RSA CA2, CN=Easy-RSA CA2
Tue Jun 21 04:39:49 2016 VERIFY OK: depth=0, O=server, CN=server
Конфигурация сервера:
port 1194
proto tcp-server
dev tun
ca ca1.crt
extra-certs ca2.crt
cert server.crt
key server-key.pem
dh dh.pem
tls-server
tls-auth ta.key 0
Конфигурация клиента:
client
remote localhost 1194
port 1194
proto tcp-client
dev tun
ca ca1.crt
extra-certs ca2.crt
cert client.crt
key client-key.pem
dh dh.pem
tls-client
tls-auth ta.key 1
Это EKU (Расширение ExtendedKeyUsage)
rfc 5280 4.2.1.12 extKeyUsage говорит
Обычно это расширение появляется только в сертификатах конечных объектов.
Базовые требования CABforum (v1.3.4) 7.2.2 g подтверждает это, но вместе с 7.1.5 допускает один случай:
Чтобы сертификат подчиненного ЦС считался технически ограниченным, сертификат ДОЛЖЕН включать расширение расширенного использования ключа (EKU), указывающее все расширенные варианты использования ключей, для которых сертификат подчиненного ЦС уполномочен выдавать сертификаты. AnyExtendedKeyUsage KeyPurposeId НЕ ДОЛЖЕН появляться в этом расширении.
Таким образом, EKU является ограничением не на использование CA собственного ключа, а на использование EE ключей с сертификатами. под CA. Это похоже на то, как политики (в основном) и NameConstraints распространяются вниз, и в отличие от KeyUsage, который делает обратиться к самому ЦС.
И это то, что реализует OpenSSL и, следовательно, делает OpenVPN с использованием OpenSSL. На каждом сертификате CA в цепочка серверов, если присутствует EKU, она должна включать serverAuth или SGC. Точно так же каждый сертификат CA в цепочке клиентов с EKU должен включать clientAuth.
Ваш промежуточный ЦС над вашим сервером имеет EKU с OCSPSign, но не serverAuth, поэтому он отклоняется.
Ссылка: crypto/x509/x509_vfy.c
и crypto/x509v3/v3_purp.c
в openssl-1.0.2h
У меня была аналогичная проблема с stunnel и openssl на linux
Я обнаружил, что серверная сторона ожидала, что все сертификаты клиента и CA будут включать: Расширенное использование ключа: проверка подлинности веб-клиента TLS.
И обнаружено, что клиентская сторона ожидала, что все сертификаты сервера и CA будут включать: Расширенное использование ключа X509v3: проверка подлинности веб-сервера TLS.
Поскольку я использовал один и тот же центр сертификации для подписания сертификатов клиента и сервера, которые я тестировал, я установил сертификаты CA, CA1 и CA2 для включения как clientAuth, так и serverAuth, и это устранило проблему.
CA, CA1 и CA2: Расширенное использование ключа X509v3: проверка подлинности веб-клиента TLS, проверка подлинности веб-сервера TLS
сертификат клиента: X509v3 Расширенное использование ключа: проверка подлинности веб-клиента TLS
сертификат сервера: X509v3 Расширенное использование ключа: Проверка подлинности веб-сервера TLS