How to generate a self-signed certificate that does not trigger warnings in browsers?

Question

I am generating a simple self-signed certificate via a simple PowerShell script leveraging openssl and then use the pfx certificate in a simple ASP.NET Core 2.0 application for enabling HTTPS)

function New-SelfSignedCertificate([string] $BaseName = 'localhost', $CommonName = 'localhost', [UInt16] $DayCount, [string] $Pass = 'somepassword')
{
    &openssl req -new -x509 -newkey rsa:2048 -keyout "$BaseName.key" -out "$BaseName.cer" -days "$DayCount" -subj /CN="$CommonName" -passout "pass:$Pass"
    &openssl pkcs12 -export -password "pass:$Pass" -passin "pass:$Pass" -out "$BaseName.pfx" -inkey "$BaseName.key" -in "$BaseName.cer"
    Remove-Item -Path "$BaseName.key"
    Remove-Item -Path "$BaseName.cer"
    Remove-Item -Path '.rnd'
}

The problem of my certificate is that it triggers a lot of warnings on every browser: Chrome, Opera, Firefox (e.g. SEC_ERROR_UNKNOWN_ISSUER), IE11 (e.g. DLG_FLAGS_INVALID_CA) and Edge (DLG_FLAGS_INVALID_CA and DLG_FLAGS_SEC_CERT_CN_INVALID), is there anything I can do at the generation to avoid those warnings? (i.e. besides adding manually the certificate to the Trusted Root category)

Seems the issuer cannot be identified, I mean how can the certificate can be judged in way that the browser would say without a user intervention: "ok you can go to the Trusted Root Certificate Authorities."? (i.e. looking for convenience during development stage).

@EJP agreed, my question is really poorly phrased and definitely off the wall, I was thinking about something similar to IIS Express (but for Kestrel) in order to bring some sort of automation during the development stage when it comes to user acceptance the certificate automatically... feel free to ask for a close. — Natalie Perret, Sep 06 '17 at 04:37
***`CN=localhost`*** is probably wrong. Hostnames always go in the *SAN*. If its present in the *CN*, then it must be present in the *SAN* too (you have to list it twice in this case). For more rules and reasons, see [How do you sign Certificate Signing Request with your Certification Authority](http://stackoverflow.com/a/21340898/608639) and [How to create a self-signed certificate with openssl?](http://stackoverflow.com/q/10175812/608639) You will also need to place the self-signed certificate in the appropriate trust store. — jww, Sep 09 '17 at 16:23

score 4 · Accepted Answer · answered Sep 05 '17 at 07:44

is there anything I can do at the generation to avoid those warnings? (i.e. besides adding manually the certificate to the Trusted Root category)

Either you don't understand the concept behind trusting a certificate or I don't understand your problem. The main idea behind the certificate validation is that the browser will detect if some hacker is diverting or intercepting your connection in order to impersonate some trusted site or to sniff sensitive (encrypted) data during a man in the middle attack.

If anybody could automatically add a CA or a certificate as trusted to the browser, i.e. without any notice to the user, then anybody could create a certificate for an arbitrary web site (like paypal.com, google.com..) and use this inside such an attack without the browser being able to detect the attack.

I mean how can the certificate can be judged in way that the browser would say without a user intervention: "ok you can go to the Trusted Root Certificate Authorities."?

This can not be set in any way by the certificate itself. Only the user or administrator or the developer of the system/browser can decide if a new CA should be considered trusted.

How to generate a self-signed certificate that does not trigger warnings in browsers?

1 Answers1