Hello Björn,
On Thu, Dec 10, 2020 at 08:14:35PM +0100, Björn Jacke wrote:
>
> What I'm finally wondering: The need for running a "set ssl cert
> fullchain.pem.ocsp" is not intended but instead the matching ocsp
> response *should* be loaded again automatically, if a certificate (with
> or without intermediate cert changes) was replaced right? If you want I
> can file an issue to track this.
The OCSP is activated by storing the configured response in a tree
during the loading of the configuration (or the set ssl cert).
This response is indexed with a key which is a OCSP_CERTID structure,
which contains the issuer name hash and the issuer key hash.
/*- CertID ::= SEQUENCE {
* hashAlgorithm AlgorithmIdentifier,
* issuerNameHash OCTET STRING, -- Hash of Issuer's DN
* issuerKeyHash OCTET STRING, -- Hash of Issuers public key
(excluding the tag & length fields)
* serialNumber CertificateSerialNumber }
*/
struct ocsp_cert_id_st {
X509_ALGOR hashAlgorithm;
ASN1_OCTET_STRING issuerNameHash;
ASN1_OCTET_STRING issuerKeyHash;
ASN1_INTEGER serialNumber;
};
A pointer to this node is then stored in the SSL context so it can be
used by the OCSP callback.
During an update with the "set ssl ocsp-response", an OCSP_CERTID is
extracted from the new response, and a lookup is done in the tree to
replace the previous one. If we didn't find the corresponding
OCSP_CERTID in the tree the message "OCSP single response: Certificate
ID does not match any certificate or issuer" is issued. This is the
problem you have because the issuer hashes changed.
If we want the "set ssl ocsp-response" command to work in this particular case,
I think we need to change the key, but the problem is that the OCSP response
only contains an OCSP_CERTID for helping us finding where we should apply the
certificate, and the serialNumber alone is not enough to index the response.
--
William Lallemand
