Istnieje kilka świetnych odpowiedzi, które podają przykłady, jak to zrobić, ale żadne nie wyjaśniają, co poszło nie tak podczas próby. OpenSSL może być czasami nieintuicyjny, dlatego warto przejść.
Po pierwsze, OpenSSL domyślnie ignoruje wszelkie wartości nazw wyróżniających podane w konfiguracji. Jeśli chcesz ich użyć, musisz dodać je prompt = no
do swojej konfiguracji. Ponadto polecenie w formie pisemnej generuje tylko
żądanie certyfikatu, a nie sam certyfikat, więc -days
polecenie nic nie robi.
Jeśli generujesz żądanie certyfikatu za pomocą tego polecenia, które podałeś i sprawdzasz wynik, obecna jest alternatywna nazwa podmiotu:
$ openssl req -new -key server.key -out server.csr -config config.cnf -sha256
$ openssl req -text -noout -in server.csr
Certificate Request:
Data:
Version: 1 (0x0)
Subject: C = US, ST = Massachusetts, L = Boston, O = MyCompany
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
...
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Subject Alternative Name:
DNS:dev.mycompany.com
Signature Algorithm: sha256WithRSAEncryption
...
Ale jeśli wygenerujesz certyfikat za pomocą polecenia w łączu heroku i sprawdzisz wynik, brak będzie alternatywnej nazwy podmiotu:
$ openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt
$ openssl x509 -text -noout -in server.crt
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
89:fd:75:26:43:08:04:61
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, ST = Massachusetts, L = Boston, O = MyCompany
Validity
Not Before: Jan 21 04:27:21 2018 GMT
Not After : Jan 21 04:27:21 2019 GMT
Subject: C = US, ST = Massachusetts, L = Boston, O = MyCompany
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
...
Exponent: 65537 (0x10001)
Signature Algorithm: sha256WithRSAEncryption
...
Powodem jest to, że domyślnie OpenSSL nie kopiuje rozszerzeń z żądania do certyfikatu. Zwykle certyfikat zostałby utworzony / podpisany przez urząd certyfikacji na podstawie żądania od klienta, a niektóre rozszerzenia mogłyby przyznać certyfikatowi większą moc niż zamierzał urząd certyfikacji, gdyby ślepo ufali rozszerzeniom zdefiniowanym w żądaniu.
Istnieją sposoby, aby powiedzieć OpenSSL, aby skopiowało rozszerzenia, ale IMHO to więcej pracy niż zwykłe udostępnianie rozszerzeń w pliku konfiguracyjnym podczas generowania certyfikatu.
Jeśli spróbujesz użyć istniejącego pliku konfiguracyjnego, nie zadziała, ponieważ sekcja najwyższego poziomu jest zaznaczona, [req]
więc te ustawienia dotyczą tylko polecenia req, a nie polecenia x509. Nie jest konieczne posiadanie znacznika sekcji najwyższego poziomu, więc możesz po prostu usunąć ten pierwszy wiersz, a wtedy będzie on działał poprawnie zarówno w przypadku generowania żądań, jak i certyfikatu.
$ openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt -extfile config.cnf
Alternatywnie można użyć -x509
argumentu req
polecenia, aby wygenerować samopodpisany certyfikat w jednym poleceniu, zamiast najpierw utworzyć żądanie, a następnie certyfikat. W takim przypadku nie jest konieczne usuwanie
[req]
wiersza sekcji, ponieważ sekcja ta jest odczytywana i używana przez polecenie req.
$ openssl req -x509 -sha256 -days 365 -key server.key -out server.crt -config config.cnf
Podsumowując, oto zmodyfikowany plik konfiguracyjny użyty w powyższych poleceniach:
default_bits = 2048
distinguished_name = dn
x509_extensions = san
req_extensions = san
extensions = san
prompt = no
[ dn ]
countryName = US
stateOrProvinceName = Massachusetts
localityName = Boston
organizationName = MyCompany
[ san ]
subjectAltName = DNS:dev.mycompany.com
-config <(cat /System/Library/OpenSSL/openssl.cnf ; printf '[SAN]\nsubjectAltName=DNS:dev.mycompany.com')