Thanks Erwann,
I appreciate your point regarding the cost of a signing operation. I plan
to take action on this. Pointing out RFC 5280 in regards to what status it
will return when it fails to download a fresh CRL helped a lot. I now see
that revoked is not "a" correct response according to the
Bonjour,
The problem with signing with a default certificate is that the response
certainly won’t be accepted by the client (see RFC6960 section 4.2.2.2, this
responder certificate doesn’t follow criteria 1 and 2, and certainly not
criteria 3), so you’re performing a signature knowing it will
Bonsoir,
The OCSP responder can respond « unknown » if it doesn’t know the status of the
requested certificate. « Unknown » can generally not be used when the issuer is
not known, because such a response is signed, and if the responder doesn’t know
about the issuer, it can’t choose its own
Thanks for chiming in Erwann. This OCSP service is CRL based. The software
I am using has a "default signing certificate". I also have #X CA specific
signing certificates for each CA in our lab PKI. It chooses to use the
default signing certificate for all unknown issuers (like if someone
Hi Walter,
I agree with your addition regarding the fact that it is not saying the
cert is good, it's saying unknown. However, my understanding of the RFC is
that unknown should be returned when the OCSP service does not know about
the certificate issuer. I'm not sure that's the case.
Regarding
Hello,
I was researching how expired CRLs affect revocation checking via openssl.
* TEST #1: *The first test was to find out what status is returned when i
verify a certificate against the CRL:
[dan@canttouchthis PKI]$ openssl verify -CAfile CAS/cabundle.pem -CRLfile
CRLS/ABC-expired.crl
Hi Dan,
On 10.12.2015 16:27, daniel bryan wrote:
*TEST #2: *Next test was using OCSP:
[dan@canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile
VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert
CERTS/0x500c8bd-revoked.pem -url http://ocspresponder:8080
/Response verify
