Tworzenie własnoręcznie podpisanego certyfikatu dla domeny i subdomen-NET:: ERR CERT nazwa zwyczajowa INVALID

Chrome 58 posiada wycofane wsparcie dla certyfikatów bez nazw alternatywnych obiektów .

Idąc dalej, może to być kolejny powód napotkania tego błędu.

Obejściem jest dodanie nazw domen, których używasz jako "subjectAltName" (x509v3 Subject Alternative Name). Można to zrobić zmieniając konfigurację OpenSSL ({[1] } w Linuksie) i zmodyfikować sekcję v3_req, aby wyglądała tak:

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.net
DNS.2 = sub1.myserver.net

Przy tym, nie zapomnij użyć przełącznika -extensions v3_req podczas generowania nowego certyfikatu. (Zobacz także Jak mogę wygenerować certyfikat z własnym podpisem z SubjectAltName przy użyciu OpenSSL?)

Utwórz plik openssl.conf:

[req]
default_bits = 2048
default_keyfile = oats.key
encrypt_key = no
utf8 = yes
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
C = US
ST = Cary
L = Cary
O  = BigCompany
CN = *.myserver.net

[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.net
DNS.2 = *.myserver.net

Uruchom ten komand:

openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout app.key -out app.crt  -config openssl.conf

Pliki wyjściowe app.crt i app.key działają dla mnie.

Your wildcard *.example.com does nie obejmuje domenę główną example.com, ale obejmuje dowolny wariant na sub -domenie, takiej jak www.example.com lub test.example.com

Preferowaną metodą jest ustalenie alternatywnych nazw przedmiotów, jak w odpowiedzi Fabiana , ale należy pamiętać, że Chrome obecnie wymaga, aby nazwa zwyczajowa była dodatkowo wymieniona jako jedna z alternatywnych nazw przedmiotów(co jest poprawnie pokazane w jego odpowiedzi). Niedawno odkryłem ten problem, ponieważ Miałem wspólną nazwę {[1] } z SANs www.example.com i test.example.com, ale dostałem Ostrzeżenie NET::ERR_CERT_COMMON_NAME_INVALID od Chrome. Musiałem wygenerować nowe żądanie podpisywania certyfikatu z example.com jako wspólną nazwą i jednym z SANs. Następnie Chrome w pełni zaufał certyfikatowi. Nie zapomnij zaimportować certyfikatu głównego do Chrome jako zaufanego organu do identyfikacji witryn internetowych.

Myślę, że to może być błąd w chrome. Był podobny problem dawno temu: Zobacz też

Spróbuj w innej przeglądarce. Myślę, że powinno działać dobrze.

Dla wszystkich, którzy napotkają to i chcą zaakceptować ryzyko, aby go przetestować, istnieje rozwiązanie: przejdź do trybu Incognito w Chrome, a będziesz mógł otworzyć " zaawansowane "i kliknąć" przejdź do niektórych.url".

Może to być pomocne, jeśli chcesz sprawdzić stronę internetową, którą sam utrzymujesz i po prostu testujesz jako programista (i kiedy nie masz jeszcze skonfigurowanego odpowiedniego certyfikatu deweloperskiego).

Oczywiście nie jest to dla osób korzystających ze strony internetowej w produkcji, gdzie to błąd wskazuje, że wystąpił problem z bezpieczeństwem witryny.

Jeśli jesteś zmęczony tym błędem. Możesz sprawić, że Chrome nie będzie się tak zachowywał. Nie mówię, że to najlepszy sposób.

Jako obejście można utworzyć klucz rejestru systemu Windows, aby umożliwić Google Chrome używanie nazwy wspólnej certyfikatu serwera w celu dopasowania nazwy hosta, jeśli certyfikat nie zawiera rozszerzenia subjectAlternativeName, o ile pomyślnie waliduje i łączy się z lokalnie zainstalowanymi certyfikatami CA.

Typ danych: Boolean [Windows: REG_DWORD] Lokalizacja rejestru systemu Windows: HKEY_LOCAL_MACHINE \ SOFTWARE\Policies\Google \ Chrome Windows / Mac / Linux / Android nazwa preferencji: EnableCommonNameFallbackForLocalanchors Wartość: 0x00000001 (Windows), true (Linux), true (Android), (Mac) Aby utworzyć klucz rejestru systemu Windows, wykonaj następujące kroki:

Otwarty Notatnik Skopiuj i wklej następującą zawartość do notatnika Windows Registry Editor Wersja 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] "EnableCommonNameFallbackForLocalanchors" = dword:00000001 Przejdź do Plik > Zapisz jako Nazwa pliku: any_filename.reg Zapisz jako typ: wszystkie Pliki

Wybierz preferowaną lokalizację pliku

Kliknij Zapisz

Kliknij dwukrotnie zapisany plik, aby uruchomić

Kliknij Tak na ostrzeżeniu edytora rejestru

Znalazłem tę informację w Pomocy Symantec strona: https://support.symantec.com/en_US/article.TECH240507.html

Odpowiedzi nie zadziałały dla mnie (Chrome lub Firefox) podczas tworzenia PWA dla lokalnego rozwoju i testowania. NIE UŻYWAĆ DO PRODUKCJI! Udało mi się użyć:

1. online certificate tools site z następującymi opcjami:
   • nazwy zwyczajowe: Dodaj zarówno "localhost", jak i IP Twojego systemu, np. 192.168.1.12
   • Alternatywne nazwy tematu: Dodaj " DNS " = "localhost" i " IP " = <your ip here, e.g. 192.168.1.12>
   • " CRS "rozwijane opcje ustawione na" Self Znak "
   • wszystkie inne opcje były domyślne
2. Pobierz wszystkie linki
3. Import .p7b cert do Windows klikając dwukrotnie i wybierając "install" / OSX?/Linux?
4. Dodano certy do aplikacji node... korzystanie z przykładu Google PWA
   • dodaj const https = require('https'); const fs = require('fs'); do górnej części serwera.plik js
   • skomentuj return app.listen(PORT, () => { ... }); na dole serwera.plik js
   • Dodaj poniżej https.createServer({ key: fs.readFileSync('./cert.key','utf8'), cert: fs.readFileSync('./cert.crt','utf8'), requestCert: false, rejectUnauthorized: false }, app).listen(PORT)

Nie mam więcej błędów w Chrome lub Firefox