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
_______________________________________________
radiator mailing list
[email protected]
https://lists.open.com.au/mailman/listinfo/radiator
