We have added two CA certificates - 1 root CA and 1 associated intermediate CA - into the according OS trust store (/etc/ssl/certs on our SuSE 11), because they weren't provided by the OS'es trust store (and probably will never, since tey are not in the repo).
Recently these two certificates disappeared after an auto-update, with the obvious effect that clients weren't able to connect via tls any longer.
In hindsight we are not sure if we did the usual rehash of the entries, i.e.
# c_rehash /etc/ssl/certs
IF we did not do the rehash: Would this have been the reason for the deletion of the according certificates during the update?
Or is there always a risk of loosing certificates if they are added to the trust store by hand (on the system in question are two ssl libraries: openssl and mozilla-nss) ?
You don't add subordinate CAs to the trust-anchor store. You only explicitly trust the Root CA (the trust-anchor) and implicitly trust all certificates signed by that Root CA or any subordinate CA of that Root.
If you can't build the chain between the end-entity and the trust-anchor then check whether the end-entity is presenting all certificates between itself and the trust-anchor. See RFC 5256 Section 7.4.2, specifically the
certificate_list
; which states that all certificates (with optionally the Root) must be presented in the TLS handshake.As an aside, Microsoft clients have the ability to download missing subordinate CA certificates if the URL to the certificate is specified in the AIA extension. Others such as Mozilla Firefox will not use that extension, citing user privacy as their justification.
Note that if you explicitly trust a subordinate CA there is no guarantee that your client will be checking the revocation of its certificate. If at a future point the subordinate is compromised and revoked by the Root CA, your client may well continue to trust it. It'll be implementation specific.