(Maybe) SSL-Bug with certificates?

[AlBundy33]

Jetty 9.4.41
java: AdoptOpenJDK 11.0.12+7
OS: SLES (server), Windows 10 (client)

Usually we're using PKCS12-Keystores (*.pfx) for SSL and this works mostly as expected.

But now I have a pfx-File that does not work as expected.
keytool -list -v -keystore test.customer.com.pfx

shows 4 entries.

1. entry
   Alias name: customer issuing
   Entry type: trustedCertEntry
   Owner: CN=Customer Issuing CA, ...
   Issuer: CN=Customer Root CA, ...

2. entry
   Alias name: customer root
   Entry type: trustedCertEntry
   Owner: CN=Customer Root CA, ...
   Issuer: CN=Customer Root CA, ...

3. entry
   Alias name: customer test.customer.com
   Entry type: PrivateKeyEntry
   Owner: CN=test.customer.com, ...
   Issuer: CN=test.customer.com, ...

Owner and Issuer are the same!

4. entry
   Alias name: customer test.customer.com issuing
   Entry type: trustedCertEntry
   Owner: CN=test.customer.com, ...
   Issuer: CN=Customer Issuing CA, ...

Issuer is the Owner of 1. entry

As you can see the PrivateKey (3. entry) has the same Issuer and Owner and the chain of trust is defined with the trustedCertEntries (1, 2 and 4)

Now if I start jetty and open the page I'll get an error that the certficated is not trusted (the root-certificate is in the windows-trust-store of course)
And if I display the certficate I don't see the chain - I see only test.customer.com

I've checked another customer-system where we also used a pfx-file and which is working as expected.
I've found out that on this system we have only one entry in the keystore and all other certficates "inside" this entry.

Does this mean that my "problem-pfx-file" is simply wrong or is this maybe a bug or unsupported configuration in jetty or maybe java?

I hope the description was clear enough, if not feel free to ask questions. :-)

[joakime]

Please copy/paste the error as you see it. (and any stacktraces too if presented).

[AlBundy33]

there is no "error" in the log.
It's "just" not working because the browser shows that the certificate is untrusted (I've tried IE, Edge, Chrome and Firefox)

All browser are showing only the certificate for the host (in my example 3. entry) and therefore the chain of trust cannot be validated because only the root-certifcated is deployed on the windows-machines.

[joakime]

To have it work on Edge / Chrome / Firefox you have to ensure that you are using a root CA that exists and is trusted by those browsers.

Speaking of Windows behaviors with Browsers ...

• Edge (based on Chromium) uses the Windows Certificate Store just fine, in fact I'm not aware of a browser specific certificate store with Edge.
• Chrome also uses the Windows Certificate Store, but often has issues with resolving content from there that isn't ALSO in the Chrome specific certificate stores.
• Firefox can support the Windows Certificate Store, but not by default, it has to be turned on (its a preference with "enterprise_roots" in its name, the exact name eludes me atm). By default it uses only the Firefox specific certificate store.

Most organizations that deal with private CAs often have to enforce specific configurations on the browsers to handle things correctly (which includes locking down browser versions, and not allowing automatic upgrades as those can break the delicate configurations of preferences in the browsers to support this private CA)

Jetty uses the Java SSL layer, so Java is basically the one in charge of sending the contents of your keystore and truststore.

You mention that Jetty is running on SLES. Have you added your custom CA root to either the truststore that Jetty sees? or the JVM's cacerts? (IIRC, SLES cannot use Windows Certificate Store)

The SSL/TLS layer has been rapidly evolving / changing over the past 5 years (at least).
Make sure you keep your JVM up to date (fyi, Java 11.0.12 expires in Oct 19, 2021), and that you read the release notes for your JVM to know what security/ssl/tls/certificate/cipher changes have occurred that could be impacting you. (eg: 11.0.12 removed support for 1024-bit or lower CA certificates, and also removed several CA roots from it's own cacerts file)

[AlBundy33]

SLES (SuSE Linux Enterprise Server) can of course not read a Windows-Truststore. :-)
The Root CA is also available on the windows-machines.

But If I check the certifiactes that are displayed in the browser there is only the certificate form test.customer.com shown.

Here is an example from google:

so I would expect

• Customer Root CA
  • Customer Issuer CA
    • test.customer.com

But currently I have only test.customer.com in the list (and therefore the browser didn't not the certifactes that where used to sign test.customer.com).
Therefore I've checked another customer-system and compared the output of keytool -v -list
I assume that this is a bug in java or jetty or maybe the pfx was generated wrong.

[sbordet]

I don't think the PrivateEntry is setup correctly.

On our website, which has a proper, non-failing, certificate signed by LetsEncrypt, we have:

Entry type: PrivateKeyEntry
Certificate chain length: 3
Certificate[1]:
Owner: CN=blogs.webtide.com
Issuer: CN=R3, O=Let's Encrypt, C=US

So the issuer is not itself, but the first CA in the chain.

[AlBundy33]

I know - on other cuetomer-systems we also have a chain where the issuer != owner for the PrivateKeyEntry.

But according to the entry type even my failing pfx seems to be correct (maybe).
private key has issuer = owner and the chain of trust is defined with entry types trustedCertEntry.

but this is only how I would read the output of keytool -list - how others would handle that file.

[sbordet]

@AlBundy33 I think this is just a KeyStore issue.

Either you properly sign and import the CSR, or you trust a self-signed certificate.

Jetty will use the KeyStore as a TrustStore if you don't explicitly specify a TrustStore, so having a trusted certificate entry in the KeyStore will also act as a trusted certificate as if it was in a TrustStore.

[AlBundy33]

Maybe this was really due to a wrongly converted file.

It seems that the customer has created the pfx manually from p7b and the private-key file.

Today I've extracted the private key and the certifactes from the from pfx and p7b and created a new pfx - it seems that this is working now because I can see the complete chain if I display the certificate in chrome.