Ostatnio Chrome przestał działać z moimi samopodpisanymi certyfikatami SSL i uważa, że nie są one bezpieczne. Kiedy patrzę na certyfikat w DevTools | Securityzakładce, widzę, że jest napisany
Brak alternatywnej nazwy podmiotu Certyfikat tej witryny nie zawiera rozszerzenia alternatywnej nazwy podmiotu zawierającego nazwę domeny lub adres IP.
Błąd certyfikatu Wystąpiły problemy z łańcuchem certyfikatów witryny (net :: ERR_CERT_COMMON_NAME_INVALID).
Jak mogę to naprawić?
CN=www.example.comjest prawdopodobnie źle. Nazwy hostów zawsze trafiają do sieci SAN . Jeśli jest obecny w CN , to musi być również obecny w SAN (w tym przypadku musisz podać go dwukrotnie). Aby uzyskać więcej zasad i powodów, zobacz Jak podpisujesz żądanie podpisania certyfikatu w urzędzie certyfikacji i Jak utworzyć certyfikat z podpisem własnym za pomocą openssl? Konieczne będzie również umieszczenie certyfikatu z podpisem własnym w odpowiednim magazynie zaufanych certyfikatów.
Odpowiedzi:
Aby to naprawić, musisz w zasadzie podać dodatkowy parametr opensslpodczas tworzenia certyfikatu
-sha256 -extfile v3.ext
gdzie v3.extjest taki plik, %%DOMAIN%%zastępowany tą samą nazwą, której używasz Common Name. Więcej informacji tutaj i tutaj . Zwróć uwagę, że zazwyczaj ustawisz Common Namei %%DOMAIN%%na domenę, dla której próbujesz wygenerować certyfikat. Więc gdyby tak było www.mysupersite.com, użyłbyś tego do obu.
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = %%DOMAIN%%
Kolejna uwaga : jeśli wszystko, co próbujesz zrobić, to powstrzymać chrome przed wyrzucaniem błędów podczas przeglądania certyfikatu z podpisem własnym, możesz poinstruować Chrome, aby ignorował wszystkie błędy SSL dla WSZYSTKICH witryn, uruchamiając go specjalną opcją wiersza poleceń, jak opisano tutaj na SuperUser
bin\openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 365 -sha256 -extfile v3.ext. Oczywiście nadal musisz zapisać v3.ext plik do pliku w tym samym folderze.
unknown option -extfile. Jak to naprawić?
extfiledyrektywy w niewłaściwym poleceniu openssl? Zamiast tego jest używany w openssl req -new ..., jest używany w openssl x509 -req .... Przynajmniej tak ktoś tutaj powiedział , co wydaje się prawdą z przykładu, który mam w innej odpowiedzi na podobne pytanie, jak w pełni wygenerować te certyfikaty
Następujące rozwiązanie zadziałało dla mnie na Chrome 65 ( ref ) -
Utwórz plik konfiguracyjny OpenSSL (przykład: req.cnf)
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = VA
L = SomeCity
O = MyCompany
OU = MyDivision
CN = www.company.com
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.company.com
DNS.2 = company.com
DNS.3 = company.net
Utwórz certyfikat odwołujący się do tego pliku konfiguracyjnego
openssl req -x509 -nodes -days 730 -newkey rsa:2048 \
-keyout cert.key -out cert.pem -config req.cnf -sha256
basicConstraints = CA:truebrakuje?
Stworzyłem skrypt bash, aby ułatwić generowanie samodzielnie podpisanych certyfikatów TLS, które są ważne w Chrome.
Testowane Chrome 65.xi nadal działa. Pamiętaj, aby ponownie uruchomić Chrome po zainstalowaniu nowych certyfikatów.
chrome://restart
Kolejnym (znacznie bardziej niezawodnym) narzędziem, które warto sprawdzić, jest cfsslzestaw narzędzi CloudFlare :
Po prostu używam -subjparametru dodającego adres IP maszyny. Tak rozwiązany za pomocą tylko jednego polecenia.
sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -sha256 -subj '/CN=my-domain.com/subjectAltName=DNS.1=192.168.0.222/' -keyout my-domain.key -out my-domain.crt
Możesz dodać inne atrybuty, takie jak C, ST, L, O, OU, emailAddress, aby generować certyfikaty bez pytania.
openssl.exe req -x509 -sha256 -newkey rsa:2048 -keyout certificate.key -out certificate.crt -days 365 -nodes -subj "/CN=my.domain.com" -addext "subjectAltName=DNS:my.domain.com" IIS wymaga *.pfxformatu:openssl.exe pkcs12 -export -out certificate.pfx -inkey certificate.key -in certificate.crt
Miałem tak wiele problemów z uzyskaniem certyfikatów z podpisem własnym działających na macOS / Chrome. W końcu znalazłem Mkcert: „Proste narzędzie o zerowej konfiguracji do tworzenia lokalnie zaufanych certyfikatów programistycznych o dowolnych nazwach”. https://github.com/FiloSottile/mkcert
Utwórz kopię swojej konfiguracji OpenSSL w swoim katalogu domowym:
cp /System/Library/OpenSSL/openssl.cnf ~/openssl-temp.cnf
lub w systemie Linux:
cp /etc/ssl/openssl.cnf ~/openssl-temp.cnf
Dodaj alternatywną nazwę podmiotu do openssl-temp.cnf, poniżej [v3_ca]:
[ v3_ca ]
subjectAltName = DNS:localhost
Zastąp localhostdomeną, dla której chcesz wygenerować ten certyfikat.
Wygeneruj certyfikat:
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-config ~/openssl-temp.cnf
-keyout /path/to/your.key -out /path/to/your.crt
Następnie możesz usunąć openssl-temp.cnf
Oto bardzo prosty sposób na utworzenie certyfikatu IP, któremu będzie ufał Chrome.
Plik ssl.conf ...
[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[ req_distinguished_name ]
commonName = 192.168.1.10
[ req_ext ]
subjectAltName = IP:192.168.1.10
Gdzie oczywiście 192.168.1.10 to adres IP sieci lokalnej, któremu chcemy ufać Chrome.
Utwórz certyfikat:
openssl genrsa -out key1.pem
openssl req -new -key key1.pem -out csr1.pem -config ssl.conf
openssl x509 -req -days 9999 -in csr1.pem -signkey key1.pem -out cert1.pem -extensions req_ext -extfile ssl.conf
rm csr1.pem
W systemie Windows zaimportuj certyfikat do zaufanego głównego magazynu certyfikatów na wszystkich komputerach klienckich. Na telefonie lub tablecie z systemem Android pobierz certyfikat, aby go zainstalować. Teraz Chrome będzie ufać certyfikatowi w systemie Windows i Android.
W programie Windows Dev Box najlepszym miejscem do pobrania openssl.exe jest „c: \ Program Files \ Git \ usr \ bin \ openssl.exe”
na MAC począwszy od wersji chrome 67.0.3396.99 mój certyfikat z podpisem własnym przestał działać.
regeneracja ze wszystkim co tu napisano nie zadziałała.
AKTUALIZACJA
miałam szansę potwierdzić, że moje podejście działa dzisiaj :). Jeśli to nie zadziała, upewnij się, że używasz tego podejścia
v3.ext
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = <specify-the-same-common-name-that-you-used-while-generating-csr-in-the-last-step>
$
skopiowane stąd https://ksearch.wordpress.com/2017/08/22/generate-and-import-a-self-signed-ssl-certificate-on-mac-osx-sierra/
KONIEC AKTUALIZACJI
w końcu był w stanie zobaczyć zielony Secure tylko po usunięciu mojego certyfikatu z systemu i dodaniu go do lokalnego pęku kluczy. (jeśli jest - najpierw go upuść). Nie jestem pewien, czy to ma znaczenie, ale w moim przypadku pobrałem certyfikat przez chrome i zweryfikowałem, że data utworzenia jest dzisiaj - więc to ta, którą właśnie utworzyłem.
mam nadzieję, że będzie to pomocne dla kogoś, kto spędził na nim dzień.
nigdy nie aktualizuj Chrome!
Jeśli chcesz uruchomić localhost serwera, musisz skonfigurować CN = localhosti DNS.1 = localhost.
[req]
default_bits = 2048
default_md = sha256
distinguished_name = req_distinguished_name
prompt = no
prompt = no
x509_extensions = v3_req
[req_distinguished_name]
C = BR
CN = localhost
emailAddress=contact@example.com
L = Sao Paulo
O = example.com
OU = example.com
ST = Sao Paulo
[v3_req]
authorityKeyIdentifier = keyid, issuer
basicConstraints = CA:FALSE
extendedKeyUsage = serverAuth
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost