Ik heb ditzelfstudie voor het maken van ondertekende SSL-certificaten op Windows voor ontwikkelingsdoeleinden, en het werkte prima voor een van mijn domeinen (ik gebruik het hosts-bestand om dns te simuleren). Toen bedacht ik dat ik veel subdomeinen had, en dat het lastig zou zijn om voor elk daarvan een certificaat te maken. Dus probeerde ik een certificaat te maken met een jokerteken in het veld Common, zoals gesuggereerd in sommige antwoorden op serverfault. Zoals dit:
Common Name: *.myserver.net/CN=myserver.net
Na het importeren van dit certificaat in Trusted Root Certification Authority, krijg ik echter een NET::ERR_CERT_COMMON_NAME_INVALID-fout in Chrome, voor het hoofddomein en al zijn subodmains, bijvoorbeeld: https://sub1.myserver.neten https://myserver.net.
Deze server kon niet bewijzen dat het mijnserver.net is; zijn veiligheidscertificaat
komt van *.mijnserver.net/CN=mijnserver.net.Dit kan worden veroorzaakt door een verkeerde configuratie of een aanvaller die uw verbinding onderschept.
Is er iets mis in het veld Algemene naam dat deze fout veroorzaakt?
Antwoord 1, autoriteit 100%
Chrome 58 heeft ondersteuning voor certificaten zonder alternatieve namen voor onderwerpen geschrapt.
In de toekomst kan dit een andere reden zijn waarom u deze fout tegenkomt.
Antwoord 2, autoriteit 47%
Een tijdelijke oplossing is om de domeinnamen toe te voegen die u gebruikt als “subjectAltName” (X509v3 Subject Alternative Name). Dit kan worden gedaan door uw OpenSSL-configuratie te wijzigen (/etc/ssl/openssl.cnfop Linux) en de sectie v3_reqer als volgt uit te laten zien:
[ 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
Als dit op zijn plaats is, vergeet dan niet om de schakelaar -extensions v3_reqte gebruiken bij het genereren van uw nieuwe certificaat. (zie ook Hoe kan ik een zelfondertekend certificaat met SubjectAltName met OpenSSL?)
Antwoord 3, autoriteit 37%
Zoals Rahul al zei, is het een veelvoorkomende Chrome- en OSX-bug. Ik had in het verleden soortgelijke problemen. In feite werd ik het eindelijk beu om de 2 [ja ik weet dat het niet veel zijn] extra klikken te maken bij het testen van een lokale site voor werk.
Wat betreft een mogelijke oplossing voor dit probleem [met Windows], zou ik met behulp van een van de vele zelfondertekenende hulpprogramma’s voor certificaten die beschikbaar zijn.
Aanbevolen stappen:
- Een zelfondertekend certificaat maken
- Certificaat importeren in Windows Certificaatbeheer
- Certificaat importeren in Chrome-certificaatbeheer
OPMERKING:Stap 3 lost het probleem op zodraGoogle de bug verhelpt… gezien de tijd in is verlopen er is geen verwachte aankomsttijd in de nabije toekomst.**Hoe graag ik Chrome ook gebruik voor ontwikkeling, ik ben beland in Firefox Developer Editiononlangs. die dit probleem niet heeft.
Ik hoop dat dit helpt 🙂
Antwoord 4, autoriteit 32%
Maak openssl.confbestand:
[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
Voer deze opdracht uit:
openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout app.key -out app.crt -config openssl.conf
Uitvoerbestanden app.crten app.keywerken voor mij.
Antwoord 5, autoriteit 23%
Uw jokerteken *.example.comdekt niethet hoofddomein example.commaar wel elke variant op een sub-domein zoals www.example.comof test.example.com
De voorkeursmethode is het instellen van alternatieve namen voor onderwerpen zoals in Fabian’s Answer, maar houd er rekening mee dat Chrome momenteel de Common vereist. Naam die aanvullend moet worden vermeld als een van de alternatieve namen van het onderwerp (zoals correct wordt aangetoond in zijn antwoord). Ik heb dit probleem onlangs ontdekt omdat ik de algemene naam example.comhad met SAN’s www.example.comen test.example.com, maar heb de waarschuwing NET::ERR_CERT_COMMON_NAME_INVALIDgekregen van Chrome. Ik moest een nieuw certificaatondertekeningsverzoek genereren met example.comals zowel de algemene naam enals een van de SAN’s. Vervolgens vertrouwde Chrome het certificaat volledig. En vergeet niet het rootcertificaat in Chrome te importeren als een vertrouwde autoriteit voor het identificeren van websites.
Antwoord 6, autoriteit 8%
Ik denk dat het een bug in Chrome is. Lang geleden was er een soortgelijk probleem:
Bekijk dit.
Probeer het in een andere browser. Ik denk dat het goed zou moeten werken.
Antwoord 7, autoriteit 2%
Voor iedereen die hiermee te maken heeft en het risico wil nemen om het te testen, is er een oplossing: ga naar de incognitomodus in Chrome en je kunt “Geavanceerd” openen en op “Doorgaan naar een.url” klikken. .
Dit kan handig zijn als u een website moet controleren die u zelf onderhoudt en alleen test als ontwikkelaar (en wanneer u nog geen juist ontwikkelingscertificaat hebt geconfigureerd).
Dit is natuurlijk NIET VOOR MENSEN die een website in productie gebruiken waar deze fout aangeeft dat er een probleem is met de websitebeveiliging.
Antwoord 8, autoriteit 2%
De gegeven antwoorden werkten niet voor mij (Chrome of Firefox) tijdens het maken van PWA voor lokale ontwikkeling en testen. NIET GEBRUIKEN VOOR PRODUCTIE! Ik kon het volgende gebruiken:
- Online certificaattools-site met de volgende opties:
- Algemene namen: voeg zowel de “localhost” als het IP-adres van uw systeem toe, b.v. 192.168.1.12
- Alternatieve namen voor onderwerpen: Voeg “DNS” = “localhost” en “IP” =
<your ip here, e.g. 192.168.1.12> - De vervolgkeuzelijst “CRS” is ingesteld op “Zelfteken”
- alle andere opties waren standaard
- Alle links downloaden
- Importeer .p7b-certificaat in Windows door te dubbelklikken en selecteer “install”/ OSX?/Linux?
- Certificaten toegevoegd aan node-app… met behulp van Google’s PWA-voorbeeld
- voeg
const https = require('https');naar de bovenkant van het server.js-bestand
const fs = require('fs'); - commentaar uit
return app.listen(PORT, () => { ... });onderaan het server.js-bestand - voeg hieronder
https.createServer({
key: fs.readFileSync('./cert.key','utf8'),
cert: fs.readFileSync('./cert.crt','utf8'),
requestCert: false,
rejectUnauthorized: false
}, app).listen(PORT)
- voeg
Ik heb geen fouten meer in Chrome of Firefox
Antwoord 9
Als je deze fout beu bent. U kunt ervoor zorgen dat Chrome zich niet zo gedraagt. Ik zeg niet dat het de beste manier is, ik zeg alleen dat het een manier is.
Als een workaround kan een Windows-registersleutel worden gemaakt om Google Chrome te laten gebruiken om de CommonName van een servercertificaat te gebruiken om een hostnaam aan te passen als het certificaat een fragmentarnativename-extensie ontbreekt, zolang het met succes een plaatselijk kan valideren geïnstalleerde CA-certificaten.
Gegevenstype: Boolean [Windows: Reg_Dword]
Windows-registerlocatie: HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Google \ Chrome
Windows / Mac / Linux / Android Preference Name: EnableCommonnamefallBackForLocalanchors
Waarde: 0x00000001 (Windows), True (Linux), True (Android), (Mac)
Ga als volgt te werk om een Windows-registersleutel te maken:Open Kladblok
Kopieer en plak de volgende inhoud in Kladblok
Windows Register Editor versie 5.00[HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Google \ Chrome]
“EnablecommonnamefallbackforLocalanchors” = DWORD: 00000001
Ga naar File & GT; Opslaan als
Bestandsnaam: iedere_filename.reg
Bewaar als type: alle bestandenSelecteer een voorkeurslocatie voor het bestand
Klik op Opslaan
Dubbelklik op het opgeslagen bestand om
uit te voeren
Klik op Ja op de Register Editor Waarschuwing
Gevonden deze informatie over Symantec Support-pagina:
https://support.symantec.com/en_us/article.tech240507.html