7

I'm using powershell New-SelfSignedCertificate to create a certificate and import into trusted root for a .netcore project.

It has been working fine, but has recently stopped, certificate doesn't expire until 2024.

I'm on Chrome 106.

Any ideas on why it would stop and how to fix?

Mat Butler
  • 101
  • 7
  • The maximum lifespan of an SSL certificate has been limited to 398 (roughly 13 months) some time ago, which may be a problem. However, it would probably be helpful if you could edit your answer to provide the exact error message. – not2savvy Oct 20 '22 at 16:38

2 Answers2

5

Yes, Chrome has introduced its own certificate root store. They say this happened back in Chrome 105 but we've only started experiencing problems since Chrome 106 on enterprise environment.

On Windows you may disable this new feature via registry:

  1. Create a REG_DWORD value ChromeRootStoreEnabled = 0 at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome
  2. Restart Chrome

Taken from chromeenterprise. But don't forget that disabling this feature without understanding what you do may be a security risk - not a big one in this case but anyway.

The docs actually state that the new root store takes locally trusted certificates into account:

The Chrome Certificate Verifier considers locally-managed certificates during the certificate verification process. This means if an enterprise distributes a root CA certificate as trusted to its users (for example, by a Windows Group Policy Object), it will be considered trusted in Chrome.

We use our own CA to sign test websites HTTPS certificates on enterprise environment. So we seemingly must not have been affected. But even though everyone on the dev team has our CA installed in trusted root - we still face this issue. I'm not sure whether it's a bug or there is something else we need to know about which CAs are accepted and which are not.

Update 2022-10-24

I found out that there is another local enterprise CA apart from out team's one. Сertificates issued by that CA are accepted by Chrome without disabling the new root store - so Chrome obviously does not ignore locally trusted certificates.

After some trial-and-error I've figured out that the problem was not about the CA certs - but about the endpoint CA-signed certificates. The old now-rejected test certificate contains these properties:

  • Basic Constraints: subject = not a CA, path length = 0
  • Key Usage: Digital Signature, Key Encipherment
  • Extended Key Usage: TLS Server, TLS Client + 9 internal custom OIDs
  • Subject Alternative Name: localhost + around 30 test websites DNS names in various domains

Removing the Basic Constraints property made Chrome finally accept the cert.

So there have been more changes to certificate validation procedure apart from the new root store. By far I haven't found any documentation about what exactly they've also changed. And AFAIK Basic Constraints is an absolutely fine property to have even in a non-CA certificate, so it looks like a bug in Chrome to me.

Stanislav Bakharev
  • 181
  • 8
  • Thank you, I'm sure this is the same issue I'm facing, and it appeared to be fine in 105 for me as well, as far as I can see it should respect the Trusted Root. I'd rather not alter the registry. But can find any other information on the issue. – Mat Butler Oct 24 '22 at 07:19
  • I've noticed that apart from our team's own internal CA there is also an "official" common corporative CA. Certs signed by the latter CA are accepted by Chrome. Both CAs are installed into LocalMachine/Trusted Root, they only differ in validity periods (rejected: 2019 to 2047, accepted: 2011 to 2031) and in a "critical" flag on the "certificate key usage" extension (true in rejected cert). Since both CAs trust is configured locally, the 398 days rule that @not2savvy mentioned is not applicable. By far I'm out of ideas but will post back if any. – Stanislav Bakharev Oct 24 '22 at 12:06
  • I've finally made Chrome accept my certificates. Updated the answer with some new info. – Stanislav Bakharev Oct 24 '22 at 17:09
  • Sorry, thought it was it. But "Basic Constraints" isn't set on my Certificates. Other properties are similar to yours. – Mat Butler Oct 25 '22 at 15:56
  • The main idea behind my update is that the problem is not just about the locally-trusted root CAs, there is something else, including some specific cert's properties. You may attach the full props list or your full call to `New-SelfSignedCertificate` and I'll try to reproduce. – Stanislav Bakharev Oct 26 '22 at 13:56
  • Thank you. I just use New-SelfSignedCertificate -DnsName $DomainName -CertStoreLocation cert:\LocalMachine\My -NotAfter (Get-Date).AddYears(24) – Mat Butler Oct 27 '22 at 10:45
  • @MatButler sorry for a big delay, had a lot of work. I've created a cert the way you described with 'localhost' domain name. After generation I've exported it via mmc and then installed into local machine's trusted root. Then I've configured it as the main SSL binding's cert for localhost and enabled back the Chrome root store. And Chrome accept it with no problems. It's possible that Chrome 107 (not 106 anymore) had some fixes or that there is something else wrong with your setup. Which error does Chrome display to you? – Stanislav Bakharev Nov 14 '22 at 09:15
  • I've also repeated this for a different domain. Created a cert on a test virtual machine for it's domain name (not localhost), configured IIS to use it and then installed it into trusted root on my machine and navigated to the website on that VM. Still no problems. – Stanislav Bakharev Nov 14 '22 at 09:27
  • Thank you for the reply. Weird I'm on 107, but still have the same issue. – Mat Butler Nov 16 '22 at 15:54
  • Thanks, the updated part of the reply was the key for me! Not using a self-signed, but a cert derived from a custom-made CA which I registered on my machine.. still, chrome 106 rejected it every time.. until I recreated che "leaf" TLS certificate it without the basic constraints set. For some reason it doesn't like them? – Luke Nov 21 '22 at 19:07
0

For people who come here because their self-made root ca certificate is accepted by firefox (after enabling windows root store in firefox) but causes ERR_CERT_AUTHORITY_INVALID in chrome:

compare your self made root ca certificate with other root ca certificates in the windows root store (trusted root ceritification authorites folder in certmgr). You can not simply allow everything as keyusage/extended keyusage. It has to match that what other root certificates use. e.g. compare with "ISRG Root X1" that is used by wikipedia for example. Firefox seems to not care about that, but chrome seems to be picky about it.

example what works:

basic constraints:

  • Subject Type=CA
  • Path Length Constraint=None

key usage:

  • Certificate Signing, Off-line CRL Signing, CRL Signing (06)

enhanced key usage:

  • Client Authentication
  • Server Authentication
Welcor
  • 2,431
  • 21
  • 32