OCSP service dependant on time valid CRLs

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

OCSP service dependant on time valid CRLs

socket
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 -crl_check CERTS/0x500c8bd-revoked.pem

CERTS/0x500c8bd-revoked.pem: C = us, O = ORG, OU = LAB, OU = ABC, OU = D002, CN = test
error 12 at 0 depth lookup:CRL has expired
C = us, O = ORG, OU = LAB, OU = ABC, OU = D002, CN = test
error 23 at 0 depth lookup:certificate revoked


as you can see the client WAS informed the certificate was revoked, even though the CRL was expired.


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 OK
CERTS/0x500c8bd-revoked.pem: unknown
This Update: Dec 9 20:48:26 2015 GMT


as you can see the client was NOT informed the certificate was revoked.

We are using a 3rd party vendors OCSP service, and I am of the opinion that an OCSP service should provide a revoked response regardless of the time validity of the CRL.

I have read RFC 2560 & 6960 many times, and have not been able to find explicit guidance on this scenario. I am interested in the community opinion on this issue, and any pertinent mandatory guidance.

My end goal is either to convince our vendor to provide a revoked status regardless of the CRLs expiration OR justify why an OCSP service should ignore issuers with expired CRLs. I'm looking forward to any feedback provided.

--Dan

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: OCSP service dependant on time valid CRLs

Walter H.
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 OK
CERTS/0x500c8bd-revoked.pem: unknown
This Update: Dec 9 20:48:26 2015 GMT


as you can see the client was NOT informed the certificate was revoked.
and also that it is not good -> unknown, revoked and good are the 3 values ...

We are using a 3rd party vendors OCSP service, and I am of the opinion that an OCSP service should provide a revoked response regardless of the time validity of the CRL.
does the OCSP responder cert be the signing cert itself or was it signed by the same signing cert that signed the cert you want to validate?

or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)?

Walter

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OCSP service dependant on time valid CRLs

socket
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 the response verification, we are used the CA Designated Responder (Authorized Responder). meaning that the issuer of serial 0x500c8bd was the same issuer of the OCSP Signing response (ABC CA3 DEV). However, my testing shows that this only affects the "response verification (OK/FAILED)" not the certificate status returned (good/revoked/unknown).

--Dan

On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <[hidden email]> wrote:
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 OK
CERTS/0x500c8bd-revoked.pem: unknown
This Update: Dec 9 20:48:26 2015 GMT


as you can see the client was NOT informed the certificate was revoked.
and also that it is not good -> unknown, revoked and good are the 3 values ...

We are using a 3rd party vendors OCSP service, and I am of the opinion that an OCSP service should provide a revoked response regardless of the time validity of the CRL.
does the OCSP responder cert be the signing cert itself or was it signed by the same signing cert that signed the cert you want to validate?

or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)?

Walter

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (5K) Download Attachment



If you reply to this email, your message will be added to the discussion below:
http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61605.html
To start a new topic under OpenSSL - User, email [hidden email]
To unsubscribe from OpenSSL - User, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: OCSP service dependant on time valid CRLs

Erwann Abalea-4
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 certificate to use to sign the response.

If your OCSP responder is CRL based, and the CRL is not valid (badly encoded, wrong signature, incomplete in scope, expired, whatever…), « unknown » is a correct answer. « revoked » is also a correct answer if an expired CRL is found declaring the requested certificate as revoked. « tryLater » is also a correct answer, even « internalError » if we consider the CRL as part of the internal state of the responder.

Erwann Abalea

Le 10 déc. 2015 à 18:29, socket <[hidden email]> a écrit :

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 the response verification, we are used the CA Designated Responder (Authorized Responder). meaning that the issuer of serial 0x500c8bd was the same issuer of the OCSP Signing response (ABC CA3 DEV). However, my testing shows that this only affects the "response verification (OK/FAILED)" not the certificate status returned (good/revoked/unknown).

--Dan

On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <<a href="x-msg://5/user/SendEmail.jtp?type=node&amp;node=61622&amp;i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
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 OK
CERTS/0x500c8bd-revoked.pem: unknown
This Update: Dec 9 20:48:26 2015 GMT


as you can see the client was NOT informed the certificate was revoked.
and also that it is not good -> unknown, revoked and good are the 3 values ...

We are using a 3rd party vendors OCSP service, and I am of the opinion that an OCSP service should provide a revoked response regardless of the time validity of the CRL.
does the OCSP responder cert be the signing cert itself or was it signed by the same signing cert that signed the cert you want to validate?

or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)?

Walter


_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: OCSP service dependant on time valid CRLs

socket
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 explicitly queries the service for a microsoft timestamp certificate).

I appreciate your definitive response regarding  that the correct answer in this situation is to return unknown. I recognize your name as an authority in pkix, but is this documented anywhere? I would like to be able to justify to my customer that this is indeed the correct response.

Also, it seems weird to me that validating this certificate against the expired CRL returns a status of revoked, but when validating this same certificate against the OCSP service it says unknown. I guess i just have to get over that they are different and that a certificate can have a different status depending on who you ask.

Looking forward to any follow on thoughts...

--Dan

On Thu, Dec 10, 2015 at 2:32 PM Erwann Abalea-4 [via OpenSSL] <[hidden email]> wrote:
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 certificate to use to sign the response.

If your OCSP responder is CRL based, and the CRL is not valid (badly encoded, wrong signature, incomplete in scope, expired, whatever…), « unknown » is a correct answer. « revoked » is also a correct answer if an expired CRL is found declaring the requested certificate as revoked. « tryLater » is also a correct answer, even « internalError » if we consider the CRL as part of the internal state of the responder.

Erwann Abalea

Le 10 déc. 2015 à 18:29, socket <[hidden email]> a écrit :

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 the response verification, we are used the CA Designated Responder (Authorized Responder). meaning that the issuer of serial 0x500c8bd was the same issuer of the OCSP Signing response (ABC CA3 DEV). However, my testing shows that this only affects the "response verification (OK/FAILED)" not the certificate status returned (good/revoked/unknown).

--Dan

On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <<a href="x-msg://5/user/SendEmail.jtp?type=node&amp;node=61622&amp;i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
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 OK
CERTS/0x500c8bd-revoked.pem: unknown
This Update: Dec 9 20:48:26 2015 GMT


as you can see the client was NOT informed the certificate was revoked.
and also that it is not good -> unknown, revoked and good are the 3 values ...

We are using a 3rd party vendors OCSP service, and I am of the opinion that an OCSP service should provide a revoked response regardless of the time validity of the CRL.
does the OCSP responder cert be the signing cert itself or was it signed by the same signing cert that signed the cert you want to validate?

or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)?

Walter


_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


If you reply to this email, your message will be added to the discussion below:
To start a new topic under OpenSSL - User, email [hidden email]
To unsubscribe from OpenSSL - User, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: OCSP service dependant on time valid CRLs

Erwann Abalea-4
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 be rejected by a compliant client. It is also unwise from your side, because anybody can send a request for free, and as a result you’ll perform a signature: non negligible CPU cost and the response is larger than the request. An unsigned error message may be better.

« Unknown » is *a* correct answer in that specific case, not the only correct one. « tryLater » and « internalError » are equivalently correct answers. « Good », « malformedRequest », and « sigRequired » are NOT correct answers. « unauthorized » may also be considered a correct answer, but others may disagree. « Revoked » may seem a correct answer also, but not quite (see below).
The meaning of those different results is explained in RFC6960 and RFC5019.
Of course, if you’re using CRLs as an authoritative source of certificate status, RFC5280 is to be read also.

Reading the algorithm described in RFC5280 section 6.3.3 to perform a CRL validation, you’ll see that:
- at step (a)(1)(ii), you don’t get a newer CRL, so you can’t continue the algorithm
- after the algorithm, reasons_masks is still the empty set, and cert_status still has the value UNREVOKED, so the revocation status has NOT been determined
- last paragraph of 6.3.3 tells you that in the end, if the revocation status has not been determined, return a cert_status UNDETERMINED.

An OCSP service based on a CRL, given an expired CRL, running this normative algorithm, will get a cert_status « UNDETERMINED », and not a value stating that it’s revoked. Such an OCSP service, responding « Revoked », wouldn’t be strictly compliant.

Erwann Abalea

Le 10 déc. 2015 à 20:07, socket <[hidden email]> a écrit :

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 explicitly queries the service for a microsoft timestamp certificate).

I appreciate your definitive response regarding  that the correct answer in this situation is to return unknown. I recognize your name as an authority in pkix, but is this documented anywhere? I would like to be able to justify to my customer that this is indeed the correct response.

Also, it seems weird to me that validating this certificate against the expired CRL returns a status of revoked, but when validating this same certificate against the OCSP service it says unknown. I guess i just have to get over that they are different and that a certificate can have a different status depending on who you ask.

Looking forward to any follow on thoughts...

--Dan

On Thu, Dec 10, 2015 at 2:32 PM Erwann Abalea-4 [via OpenSSL] <<a href="x-msg://7/user/SendEmail.jtp?type=node&amp;node=61628&amp;i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
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 certificate to use to sign the response.

If your OCSP responder is CRL based, and the CRL is not valid (badly encoded, wrong signature, incomplete in scope, expired, whatever…), « unknown » is a correct answer. « revoked » is also a correct answer if an expired CRL is found declaring the requested certificate as revoked. « tryLater » is also a correct answer, even « internalError » if we consider the CRL as part of the internal state of the responder.

Erwann Abalea

Le 10 déc. 2015 à 18:29, socket <[hidden email]> a écrit :

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 the response verification, we are used the CA Designated Responder (Authorized Responder). meaning that the issuer of serial 0x500c8bd was the same issuer of the OCSP Signing response (ABC CA3 DEV). However, my testing shows that this only affects the "response verification (OK/FAILED)" not the certificate status returned (good/revoked/unknown).

--Dan

On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <<a href="<a href="x-msg://5/user/SendEmail.jtp?type=node&amp;amp;node=61622&amp;amp;i=0" class="">x-msg://5/user/SendEmail.jtp?type=node&amp;node=61622&amp;i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
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 OK
CERTS/0x500c8bd-revoked.pem: unknown
This Update: Dec 9 20:48:26 2015 GMT


as you can see the client was NOT informed the certificate was revoked.
and also that it is not good -> unknown, revoked and good are the 3 values ...

We are using a 3rd party vendors OCSP service, and I am of the opinion that an OCSP service should provide a revoked response regardless of the time validity of the CRL.
does the OCSP responder cert be the signing cert itself or was it signed by the same signing cert that signed the cert you want to validate?

or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)?

Walter


_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


If you reply to this email, your message will be added to the discussion below:
To start a new topic under OpenSSL - User, email <a href="x-msg://7/user/SendEmail.jtp?type=node&amp;node=61628&amp;i=1" target="_top" rel="nofollow" link="external" class=""> [hidden email]
To unsubscribe from OpenSSL - User, click here.
NAML


View this message in context: Re: OCSP service dependant on time valid CRLs
Sent from the OpenSSL - User mailing list archive at Nabble.com.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: OCSP service dependant on time valid CRLs

socket
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 logic defined in the RFC. I do feel that since a certificate can not be unrevoked (with the exception of "on hold") that if an OCSP service learns that serial #X was once revoked with a reason code of (anything bit on hold), therefor it must still be revoked.  Am I wrong in thinking this? Is it more safe to completely disregard an expired CRLs?

--Dan

On Fri, Dec 11, 2015 at 9:15 AM Erwann Abalea <[hidden email]> wrote:
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 be rejected by a compliant client. It is also unwise from your side, because anybody can send a request for free, and as a result you’ll perform a signature: non negligible CPU cost and the response is larger than the request. An unsigned error message may be better.

« Unknown » is *a* correct answer in that specific case, not the only correct one. « tryLater » and « internalError » are equivalently correct answers. « Good », « malformedRequest », and « sigRequired » are NOT correct answers. « unauthorized » may also be considered a correct answer, but others may disagree. « Revoked » may seem a correct answer also, but not quite (see below).
The meaning of those different results is explained in RFC6960 and RFC5019.
Of course, if you’re using CRLs as an authoritative source of certificate status, RFC5280 is to be read also.

Reading the algorithm described in RFC5280 section 6.3.3 to perform a CRL validation, you’ll see that:
- at step (a)(1)(ii), you don’t get a newer CRL, so you can’t continue the algorithm
- after the algorithm, reasons_masks is still the empty set, and cert_status still has the value UNREVOKED, so the revocation status has NOT been determined
- last paragraph of 6.3.3 tells you that in the end, if the revocation status has not been determined, return a cert_status UNDETERMINED.

An OCSP service based on a CRL, given an expired CRL, running this normative algorithm, will get a cert_status « UNDETERMINED », and not a value stating that it’s revoked. Such an OCSP service, responding « Revoked », wouldn’t be strictly compliant.

Erwann Abalea

Le 10 déc. 2015 à 20:07, socket <[hidden email]> a écrit :

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 explicitly queries the service for a microsoft timestamp certificate).

I appreciate your definitive response regarding  that the correct answer in this situation is to return unknown. I recognize your name as an authority in pkix, but is this documented anywhere? I would like to be able to justify to my customer that this is indeed the correct response.

Also, it seems weird to me that validating this certificate against the expired CRL returns a status of revoked, but when validating this same certificate against the OCSP service it says unknown. I guess i just have to get over that they are different and that a certificate can have a different status depending on who you ask.

Looking forward to any follow on thoughts...

--Dan
On Thu, Dec 10, 2015 at 2:32 PM Erwann Abalea-4 [via OpenSSL] <[hidden email]> wrote:
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 certificate to use to sign the response.

If your OCSP responder is CRL based, and the CRL is not valid (badly encoded, wrong signature, incomplete in scope, expired, whatever…), « unknown » is a correct answer. « revoked » is also a correct answer if an expired CRL is found declaring the requested certificate as revoked. « tryLater » is also a correct answer, even « internalError » if we consider the CRL as part of the internal state of the responder.

Erwann Abalea

Le 10 déc. 2015 à 18:29, socket <[hidden email]> a écrit :

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 the response verification, we are used the CA Designated Responder (Authorized Responder). meaning that the issuer of serial 0x500c8bd was the same issuer of the OCSP Signing response (ABC CA3 DEV). However, my testing shows that this only affects the "response verification (OK/FAILED)" not the certificate status returned (good/revoked/unknown).

--Dan

On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <<a href="x-msg://5/user/SendEmail.jtp?type=node&amp;node=61622&amp;i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
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 OK
CERTS/0x500c8bd-revoked.pem: unknown
This Update: Dec 9 20:48:26 2015 GMT


as you can see the client was NOT informed the certificate was revoked.
and also that it is not good -> unknown, revoked and good are the 3 values ...

We are using a 3rd party vendors OCSP service, and I am of the opinion that an OCSP service should provide a revoked response regardless of the time validity of the CRL.
does the OCSP responder cert be the signing cert itself or was it signed by the same signing cert that signed the cert you want to validate?

or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)?

Walter


_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


If you reply to this email, your message will be added to the discussion below:
To start a new topic under OpenSSL - User, email [hidden email]
To unsubscribe from OpenSSL - User, click here.
NAML
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users