Windows-ROOT as truststore

[amaljesudas]

Is there a way to set Windows-ROOT (or any Windows Certificate Store in general) as truststore in openssl?
I think java has some similar feature.

Thanks in advance.

[hlandau]

OpenSSL has never had code to load the Windows certificate store itself. It's a somewhat surprising asymmetry given that it does have code to load the system certificate store on *nix and it already is willing to use the Win32 crypto API for some things (like CryptGenRandom).

It's only about 35 lines of code to do this though. Here's some (now rather old) code of mine (not guaranteed, but feel free to use): https://gist.github.com/hlandau/7a9a8146af25a2c972aa1fe400a8a60f

@mattcaswell Do we want this functionality?

[kroeckx]

You could argue that *nix systems use OpenSSL store mechanisme, not the other way around.

[amaljesudas]

@hlandau

Thanks for the info and code Hugo.
I did try a similar implementation to what you provided, but was not able to get my connection to work (could be some other issue, checking on it).
As you mentioned, OpenSSL does not have direct code to load from Windows Certificate Store.
Do you know why this is not implemented? Is it because of some known issue or use case limitation?
Just wanted to know from an academic perspective.

[t8m]

Do you know why this is not implemented? Is it because of some known issue or use case limitation?

In general OpenSSL is an open source software which means a feature gets implemented when someone who needs it submits a code that implements the feature. So the answer is that nobody submitted the code that implements Windows cert store support.

Why nobody did that that's another question which we probably cannot answer.

[hlandau]

@t8m Would we be interested in this functionality? I have code to do it lying around and it seems like basically anyone using libssl on Windows will need it. I could make a PR.

[t8m]

I do not see why we would not want it. The difficult question would be how that windows cert store will be enabled. I.E. making it enabled by default on Windows might be considered a too big change for 3.1 by some.

[paulidale]

The question for me is would this impact the 3.1 development times?

[hlandau]

It's not much code. About 35 lines. I already have it from my own projects. Biggest timesink would just be agreeing the API/how it interacts with existing functions.

[t8m]

Ideally it would be done in terms of OSSL_STORE provider instead of adding certs to X509_STORE which complicates that 35 line code quite some.

[levitte]

A minimum provider that does this only needs an OSSL_STORE loader with export capabilities. That's enough to handle any key where the key data is programmatically accessible (i.e. exportable) and shouldn't be too hard to do. The main thing will probably be to design the URI scheme and implement its parser.

[levitte]

... when we do design such a URI scheme, we probably should register it properly too. I know that I've mentioned the sneaky way of avoiding that, but I frankly think making it official is the better move in the long run.

[hlandau]

@levitte See #18070? Currently the issue is that SSL_CERT_DIR is interpreted both as a colon-separated list of paths and as a store URI.

[levitte]

Ah, thanks for the reminder.