Re: [openssl-users] 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] <
ml-node+s6102n61627...@n7.nabble.com> 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
> [hidden email] <http:///user/SendEmail.jtp?type=node=61627=0>
>
> Le 10 déc. 2015 à 18:29, socket <[hidden email]
> <http:///user/SendEmail.jtp?type=node=61627=1>> 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] < href="x-msg://5/user/SendEmail.jtp?type=nodenode=61622i=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:
>
> http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61627.html
> To start a new topic under OpenSSL - User, email
> ml-node+s6102n3...@n7.nabble.com
> To unsubscr

Re: [openssl-users] 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] <
ml-node+s6102n61605...@n7.nabble.com> 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
> ml-node+s6102n3...@n7.nabble.com
> To unsubscribe from OpenSSL - User, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61622.html
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

MODSSL: RFC 2560

[socket]

Hey all, I am wondering if anyone here could point me in the right direction
or even assist with a problem I have having.

According to RFC 2560:

All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
 *  -- a Trusted Responder whose public key is trusted by the requester*
   -- a CA Designated Responder (Authorized Responder) who holds a
  specially marked certificate issued directly by the CA, indicating
  that the responder may issue OCSP responses for that CA

I have Root CA1(RCA1), and Root Ca2(RCA2). also, I have Intermediate
Authority 1(IA1) and Intermediate Authority 2 (IA2). I have an OCSP signing
certificate issued from IA1 (ocsp1).
I have apache 2.4 configured with trust for rca1, rca2, ia1, ia2 and I am
able to use client authentication to login with either client cert 1(cc1),
or Clicnet Cert 2(cc2). 

However, when I enable OCSP it acts differently:
SSLVerifyClient on
SSLVerifyDepth  4
SSLOCSPEnable on
SSLOCSPDefaultResponder http://rsp.domain.com:80/
SSLOCSPOverrideResponder on

I am able to successfully validate cc1 and any other client certificates
issued from ia1.  However, when I try to use cc2, I get the following error:
*SSL Library Error: error:27069070:OCSP routines:OCSP_basic_verify:root ca
not trusted*

Looking at a post in the past:
http://openssl.6102.n7.nabble.com/OCSP-basic-verify-root-ca-not-trusted-td24451.html

it seems that the RFC should allow me to explicitly declare a trusted
responder certificate for the client machine (in this case the client is the
httpd 2.4 server). However it doesn't seem that mod_ssl allows me to declare
this. 

I would like to know: 
Am i right in thinking I should be able to do this?
Who currently supports mod_ssl and how would i present a change request?
Does mod_ssl currently support this feature unbenounced to me?
if not, would anyone be willing to teach me how to modify mod_ssl to support
something like: *'SSLOCSPTrusted_responder
/etc/pki/tls/certs/trustedresponder.pem'*
Other applications like openssl and corestreet desktop validation client
allow you to explicitly configure a trusted responder cert.
eg: openssl ocsp -CAfile rca2-issuer ia2 -cert cc2 -VAfile ocsp1 -url
http://rsp.domain.com:80
cc2: good
This Update: Jan 14 10:02:14 2014 GMT
Next Update: Feb 14 10:02:14 2014 GMT



--
View this message in context: 
http://openssl.6102.n7.nabble.com/MODSSL-RFC-2560-tp48136.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: MODSSL: RFC 2560

[socket]

What I am saying is that one falls into the delegated trust model, and one
does not, but I should be able to validate either because RFC 2560 allows
for a Trusted Responder whose public key is trusted by the requester. I am
asking if mod_ssl in apache 2.4.x is RFC compliant. it seems to me openssl
supports this explicitly via the -VAflag, but mod_ssl doesn't.

*Trustpoint 1:*

[root@va][/usr/local/apache2/conf]
openssl verify -CAfile rca1 cc1
cc1: OK

[root@va][/usr/local/apache2/conf]
openssl ocsp -CAfile rca1 -issuer rca1 -cert cc1 -no_nonce -url
http://localhost:3503
Response verify OK
cc1: good
This Update: Jan 10 21:16:11 2014 GMT
Next Update: Jan 18 09:36:11 2014 GMT

*Trust Point 2:*

[root@va][/usr/local/apache2/conf]
openssl verify -CAfile rca2 ia2
ia2: OK

[root@va][/usr/local/apache2/conf]
openssl verify -CAfile rca2 cc2
cc2: OK

[root@va][/usr/local/apache2/conf]
openssl ocsp -CAfile rca2 -issuer ia2 -cert cc2 -no_nonce -url
http://localhost:3503
Response Verify Failure
140278240200520:error:27069065:OCSP routines:OCSP_basic_verify:certificate
verify error:ocsp_vfy.c:126:Verify error:unable to get local issuer
certificate
cc2: good
This Update: Jan 14 10:02:14 2014 GMT
Next Update: Feb 14 10:02:14 2014 GMT

*But if i explicitly declare the trusted VA:*I get no errors.
[root@va][/usr/local/apache2/conf]
openssl ocsp -CAfile rca2 -issuer ia2 -cert cc2 -no_nonce *-VAfile ocsp1*
-url http://localhost:3503
Response verify OK
cc2: good
This Update: Jan 14 10:02:14 2014 GMT
Next Update: Feb 14 10:02:14 2014 GMT






--
View this message in context: 
http://openssl.6102.n7.nabble.com/MODSSL-RFC-2560-tp48136p48141.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org