Load root certificates at image build time

[christianwimmer]

The JDK ships a file with root certificates: lib/security/cacerts. The JDK TrustStoreManager is responsible for loading. If no system property is set explicitly, then the cacerts file of the JDK is loaded. But that can be overridden using system properties.

We have a few options how to handle that in a native image:

1. Do not embed any root certificates into a native image. That means that the application needs to be shipped with a cacerts file, or the system properties must be used to locate certificates already installed on the system. I think that is a bad option though because it is difficult for users, and no certificates are available out-of-the-box without additional configuration.
2. Embed the root certificates into the native image, but still at run time look at the system properties and allow certificates from an alternative location to be loaded.
3. Embed the root certificates into the native image, and do not allow any different certificates to be loaded at run time.

The difference between option 2) and 3) from a security and usability perspective: In option 2) we treat security as something that can be configured at image run time. In option 3), we consider security as something that is fixed at image build time and therefore cannot be modified (explicitly or accidentally) at run time.

We believe that "immutable security" is a valuable feature of Native Image and therefore implement solution 3)

[dmlloyd]

I would prefer solution "1" or "2", if anything. I'm not sure that "immutable security" is a feature per se; it's more of a consequence.

[sberyozkin]

@christianwimmer It is not clear if 3) allows for the custom certificates be included at the build time ?

Option 2) looks the best though, can you please clarify why 3) is preferred to letting the native image users customize the default certificates at run time ?

[christianwimmer]

@sberyozkin Yes, custom certificates can be included at image build time. All system properties such as javax.net.ssl.trustStore can be specified at image buid time.

@dmlloyd "immutable security" is a guiding principle of Native Image. For example, not allowing dynamic class loading at run time makes the code immutable at run time, allowing to reason about security at image build time. Do you have any technical arguments or use cases why solution 3) would not work?

[dmlloyd]

@dmlloyd "immutable security" is a guiding principle of Native Image. For example, not allowing dynamic class loading at run time makes the code immutable at run time, allowing to reason about security at image build time. Do you have any technical arguments or use cases why solution 3) would not work?

No, I think it will work, but I suspect we'll end up having to add a Quarkus workaround to allow the trust store to be rebuilt from cacerts at run time, which is not ideal.

[sberyozkin]

@christianwimmer, thanks...

Do you have any technical arguments or use cases (for 2))

The native image HTTP client target URI varies per deployment thus making it difficult to anticipate which certificates have to be included at the build time.

[christianwimmer]

But we are only talking about the root certificates here. So do you have an actual use case where you right now set the javax.net.ssl.trustStore property for a Java VM to a certificate store that you do not have available at image build time?

[dmlloyd]

I guess that depends on the length of time one expects a native image to be in use for. If you expect the image to be rebuilt every few weeks or even months, it's probably okay. Longer than that, it may become a problem at some point.

[fcurts]

Option 3 rules out the use of binary distributions of third-party applications that don't contain the root certificates you need. (Based on my experience, it's not uncommon for corporations to have their own root certificates for internal use.) Hence option 2 seems more desirable to me, even though I'd generally want to set the alternative location(s) at build time (to the trust store of the target OS). This is also how standard tools such as curl work.

[fcurts]

@christianwimmer @dmlloyd Any more thoughts on this? I'm concerned that option 3 rules out the use of native-image for many use cases (including mine). I'm writing a CLI based tool that needs to fetch data over the network. In corporate environments this often requires internal certificates, which are typically available from the OS trust store. It doesn't seem reasonable to ask each of my users to build my tool on their own and add their certificates at build time.

To summarize my point, option 3 may be good enough for services, but isn't good enough for tools.

[zeeZ]

Saw this "immutable security" thing mentioned in quarkusio/quarkus/issues/9713

Option 3 makes it very hard to build and test a single native image and use it in multiple environments with their own internal CA.

You're forced to either include and trust all CA from all environments at build time (why should an image run in production trust a certificate signed by the test environment CA?) or rebuild the image for each environment (no more build once, deploy anywhere). Testing in a dynamic environment where the CA is not known at build time becomes impossible.

IMHO a truststore is closer to application configuration than it is to application logic, and 3) is a step too far.

[collinpeters]

Does option 3 as a default for Graal actually preclude the ability for someone to use option 2 in their own binary? i.e. can I not just provide an option to my binary which will load additional trusted stores? I haven't spent much time Googling around for a good example, but this post on SO implies that if you haven't instantiated any SSL connections you can do System.setProperty( "javax.net.ssl.trustStore", "/usr/local/comp.jks" ); and set your own trust store.