Creating self signed certificate for domain and subdomains - NET::ERR_CERT_COMMON_NAME_INVALID

前端 未结 9 2122
后悔当初
后悔当初 2020-12-04 10:27

I followed this tutorial for creating Signed SSL certificates on Windows for development purposes, and it worked great for one of my domains(I\'m using hosts file to simulat

相关标签:
9条回答
  • 2020-12-04 11:18

    The answers provided did not work for me (Chrome or Firefox) while creating PWA for local development and testing. DO NOT USE FOR PRODUCTION! I was able to use the following:

    1. Online certificate tools site with the following options:
      • Common Names: Add both the "localhost" and IP of your system e.g. 192.168.1.12
      • Subject Alternative Names: Add "DNS" = "localhost" and "IP" = <your ip here, e.g. 192.168.1.12>
      • "CRS" drop down options set to "Self Sign"
      • all other options were defaults
    2. Download all links
    3. Import .p7b cert into Windows by double clicking and select "install"/ OSX?/Linux?
    4. Added certs to node app... using Google's PWA example
      • add const https = require('https'); const fs = require('fs'); to the top of the server.js file
      • comment out return app.listen(PORT, () => { ... }); at the bottom of server.js file
      • add below https.createServer({ key: fs.readFileSync('./cert.key','utf8'), cert: fs.readFileSync('./cert.crt','utf8'), requestCert: false, rejectUnauthorized: false }, app).listen(PORT)

    I have no more errors in Chrome or Firefox

    0 讨论(0)
  • 2020-12-04 11:26

    If you're tired of this error. You can make Chrome not act out like this. I'm not saying it's the best way just saying it's a way.

    As a workaround, a Windows registry key can be created to allow Google Chrome to use the commonName of a server certificate to match a hostname if the certificate is missing a subjectAlternativeName extension, as long as it successfully validates and chains to a locally-installed CA certificates.

    Data type: Boolean [Windows:REG_DWORD] Windows registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome Windows/Mac/Linux/Android preference name: EnableCommonNameFallbackForLocalAnchors Value: 0x00000001 (Windows), true(Linux), true (Android), (Mac) To create a Windows registry key, simply follow these steps:

    Open Notepad Copy and paste the following content into notepad Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] "EnableCommonNameFallbackForLocalAnchors"=dword:00000001 Go to File > Save as Filename: any_filename.reg Save as type: All Files

    Select a preferred location for the file

    Click on Save

    Double click on the saved file to run

    Click on Yes on the Registry Editor warning

    Found this information on Symantec support page: https://support.symantec.com/en_US/article.TECH240507.html

    0 讨论(0)
  • 2020-12-04 11:27

    Your wildcard *.example.com does not cover the root domain example.com but will cover any variant on a sub-domain such as www.example.com or test.example.com

    The preferred method is to establish Subject Alternative Names like in Fabian's Answer but keep in mind that Chrome currently requires the Common Name to be listed additionally as one of the Subject Alternative Names (as it is correctly demonstrated in his answer). I recently discovered this problem because I had the Common Name example.com with SANs www.example.com and test.example.com, but got the NET::ERR_CERT_COMMON_NAME_INVALID warning from Chrome. I had to generate a new Certificate Signing Request with example.com as both the Common Name and one of the SANs. Then Chrome fully trusted the certificate. And don't forget to import the root certificate into Chrome as a trusted authority for identifying websites.

    0 讨论(0)
提交回复
热议问题