[RADIATOR] OCSP validation

[Heikki Vatiainen]

On 16.8.2023 13.31, Stefan Paetow (OpenSource) via radiator wrote:

> 036004: DEBUG: ServerRADSEC (EDUROAM_RADSEC) TLS OCSP response 
> verification 
> '3045300906052b0e03021a05000414e0edac4bf41cfcbce33a156b554e92fac28f0c5c0414d2f223bd4aa17fcfa05884ebfce65b08b3cdb4e4020c2427658a363cc6c6452df2e2' failed: 0

> I've redacted the source IP and the subject. I look at the 'response 
> verification' line (036004) where the result code is 0, which usually 
> means it was successful.

Net::SSLeay::OCSP_response_verify() returns 0 for failure, which was 
correctly noticed by Radiator.

https://github.com/radiator-software/p5-net-ssleay/blob/master/lib/Net/SSLeay.pod#L515C1-L523

> And yeah, like you say, you use APIs, and I considered whether adding 
> the CA certificate into the trusted store on the machine would make a 
> difference, but it doesn't appear so. Is there possibly an assumption 
> within Net::SSLeay that if you don't specify a certificate somehow to 
> verify the response with that the trusted store is used? :-/

Looking at Net::SSLeay, there are comments and code that attempt to set 
up store for verification:

https://github.com/radiator-software/p5-net-ssleay/blob/master/SSLeay.xs#L7739-L7753

The respective Changelog entry is:

https://github.com/radiator-software/p5-net-ssleay/blob/master/Changes#L1112


> I will note though that the response does not include a nonce (if the 
> request contains one), although that's not a requirement... This is the 
> case when I use 'openssl verify', so I assume the same applies to the API.

Net::SSLeay::OCSP_response_verify() doesn't require nonce. Only if 
there's an incorrect nonce, then it will trigger a failure.

The OCSP responder ( http://ocsp.edupki.org/OCSP-Server/OCSP ) 
certificate is signed by this root CA:

   https://www.edupki.org/fileadmin/Documents/edupki-root-ca-cert.txt

If I add this CA to TLS_CAFile, then the OCSP response verification 
succeeds. I tested this by forcing the verification to use the request 
shown in your log.

However, I'm not sure if this is the right approach if you otherwise 
don't want to trust that CA for RadSec connections. I haven't touched 
the OCSP functionality in Net::SSLeay and it's unclear for me, for 
example, if it's permissible to use different CAs for OCSP response 
verification. That is, different CAs than what the verified certificates 
use.

If you append edupki-root-ca-cert.txt to the file pointed by TLS_CAFile, 
does it work then? And if it does, is this an acceptable CA certificate? 
Since 'TLS_CAFile %D/cert/roaming-eduPKI-CA.crt' didn't work for you, 
it's a different root CA?

I guess the main question is that how the trust chains are supposed to be.


-- 
Heikki Vatiainen
OSC, makers of Radiator
Visit radiatorsoftware.com for Radiator AAA server software