PKI generated certificates are not considered as trusted even if root CA added to the trust store.

[pdomineaux]

Describe the bug

When creating certificate with the new PKI feature, the certificate are not valid for Chrome but are OK for Safari.

To Reproduce

Steps to reproduce the behavior:

1. Create a CA
2. Create Certificate with SANs (fqdn only as IP Addresses are not valid in the field)
3. Get both root CA and server certificate
4. Import the Root CA into the keychain and set the Trust to "Always Trust"
5. Set the private key and cert to the server
6. Add the entry in /etc/hosts to match fqdn
7. Browse to the server fqdn

Expected behavior

I expect the certificate to be trusted by my browser

Screenshots

If applicable, add screenshots to help explain your problem.

Platform you are having the issue on:

I'm using Infisical self-hosted with version 0.80.0-postgres

Additional context

It work on Safari.

With Firefox: Warning: Potential Security Risk Ahead but I can accept the exception and continue browsing

With Chrome, browsing is not possible: server.local normally uses encryption to protect your information. When Chrome tried to connect to server.local this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be server.local, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Chrome stopped the connection before any data was exchanged.

You cannot visit server.local right now because the website sent scrambled credentials that Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later.

[dangtony98]

Thanks for raising this issue @pdomineaux.

I'll be looking into this as we continue working on the new PKI feature — I don't have an estimated time frame for resolution yet given there're a lot of ongoing development but will keep you posted.

[pdomineaux]

To complete my issue. I've tested the certs with openssl:

openssl verify -CAfile MyRootCert.pem -untrusted MyIntermediateCert.pem server.pem
servercert.pem: OK

But I still get the Chrome/Brave Browser error: net::ERR_CERT_INVALID

[gs-kug]

I'm facing the same issue, and the certificate proposed is not match the intention usage (not sure what is the right code here)

Second image is in portuguese. Translating: "This certificate or certificate chain are not valid for the usage mode intended."

[gs-kug]

As reference if you pick any valid certificate it should show a valid code:

[gs-kug]

Oh, this is happening through the chain. So anyone using this feature will need to rotate or delete all CA certificates, reisuing everything... I think you guys should add a warning on the document page that this feature is experimental. This kind of bug is an oversight, and imagine a big company root CA deployment. It would be a mess. Please let me know if I'm wrong here.

[sheensantoscapadngan]

Hey @pdomineaux and @gs-kug! We've just pushed an update that resolves the issue with the EKUs in the root CAs. You'll need to renew your root CAs and migrate to this new root certificate.

Additionally, you can now configure key usage and extended key usage extensions during the issuance flow, allowing more flexibility in customizing certificate extensions.

Apologies for this oversight. Do let me know if you need any further assistance!

[pdomineaux]

Thank you for your responsiveness. It works like a charm. I had to :

• include the chain in the leaf certificate for this to work as I 've only add the ROOT CA in my trust store.
• be sure to add the Common Name (CN) (i.e server-01.leaf.local) also in the Alternative Names (SANs).

If you don't add the last one, there will be an error saying that the certificate's name does not match if you try to access the server with the Common Name.