Trouble with OCSP

[Orion Poplawski]

On 12/4/24 14:51, orion at nwra.com wrote:
> On 12/4/24 12:03, orion at nwra.com wrote:
>> On 12/4/24 10:40, Alan DeKok wrote:
>>> On Dec 4, 2024, at 11:53 AM, Orion Poplawski <orion at nwra.com> wrote:
>>>> I think it is just having trouble with ocsp checks of certs issued by the
>>>> older AD CA cert.  Here is a successful check of an IPA issued cert:
>>>> ..
>>>> It also has the message about untrusted certs (although it also mentions
>>>> the CA cert - so maybe the windows clients don't provide it?), so that
>>>> does not seem particularly relevant.  I guess the key then is:
>>>>
>>>> (14) eap_tls: ERROR: ocsp: Couldn't verify OCSP basic response
>>>>
>>>> But why?  openssl doesn't complain:
>>>
>>>    We call an OpenSSL function to do the OCSP verification, and that
>>> function returns "failed".  Why?  OpenSSL magic.
>>>
>>>    i.e. OpenSSL doesn't give FreeRADIUS any reason why.  There's just a
>>> "failed" response.  No error result, nothing useful which we can print.
>>>
>>>> $ openssl ocsp -issuer /etc/pki/ca-trust/source/anchors/ ad.nwra.com.crt -
>>>> cert orionad.crt -url http://ocsp.ad.nwra.com/ocsp
>>>> Response verify OK
>>>> orionad.crt: good
>>>>         This Update: Dec  3 17:50:03 2024 GMT
>>>>         Next Update: Dec  5 06:10:03 2024 GMT
>>>
>>>    You're passing the issuer here, though.  OpenSSL needs the *entire*
>>> certificate chain for verification.  If it only has an intermediate
>>> certificate, then it will fail.
>>>
>>>    So did you add the issuer certificate to the FreeRADIUS configuration? 
>>> i.e. put it into "ca_path".
>>
>> I have:
>>
>>     tls-config tls-common {
>>          verify_depth = 0
>>          ca_path = "/etc/raddb/certs"
>>          pem_file_type = yes
>>          private_key_file = "/etc/pki/tls/private/FQDN.key"
>>          certificate_file = "/etc/pki/tls/certs/FQDN.crt"
>>          ca_file = "/etc/raddb/certs/nwra_ad_ipa_ca.crt"
>>          private_key_password = <<< secret >>>
>>          fragment_size = 1024
>>          include_length = yes
>>          auto_chain = yes
>>          check_crl = no
>>          check_all_crl = no
>>          ca_path_reload_interval = 0
>>          cipher_list = "DEFAULT"
>>          cipher_server_preference = no
>>          reject_unknown_intermediate_ca = no
>>          ecdh_curve = "prime256v1"
>>          tls_min_version = "1.2"
>>      cache {
>>          enable = no
>>          lifetime = 24
>>          max_entries = 255
>>      }
>>      verify {
>>          skip_if_ocsp_ok = no
>>      }
>>      ocsp {
>>          enable = yes
>>          override_cert_url = no
>>          url = "http://ocsp.ad.nwra.com/ocsp/"
>>          use_nonce = yes
>>          timeout = 0
>>          softfail = no
>>      }
>>     }
>>
>> ca_file's nwra_ad_ipa_ca.crt contains all 3 of our CA certs in use. There
>> are no intermediate certs.
>>
>> I did just now realize that ca_path would not have been working properly
>> currently because openssl rehash requires all of the files there to only
>> contain 1 cert.  So I split the AD CA cert file into two, rehashed again,
>> and tried again - but I'm still getting the same failure.
>>
>> lrwxrwxrwx. 1 root root      16 Dec  4 11:00 241bed0c.0 -> ad.nwra.com2.crt
>> lrwxrwxrwx. 1 root root      15 Dec  4 11:00 241bed0c.1 -> ad.nwra.com.crt
>> lrwxrwxrwx. 1 root root      10 Sep  1  2023 599be2cf.0 -> ipa_ca.crt
> 
> I think I've figured out how to get a working config again by dropping ca_file
> and having a working ca_path - but it seems like there might be a bug in
> freeradius, or at least in the docs, let me know what you think.
> 
> This seems to be the same issue as this:
> https://serverfault.com/questions/1090456/freeradius-with-mixed-cas

Well, while I *thought* I had this briefly working, when I went to really
deploy this it turns out that it is not.  It appears to fail to verify OCSP
responses for older AD certs issued by the previous AD CA cert.

After some more reading and experimenting, I've come to the conclusion that by
default openssl requires the CA cert that issued the client cert be the same
as the CA cert that issued the OCSP signing cert used to sign the ocsp response.

However, with the Microsoft CA and OCSP responder - the signing certificate
validity is quite short - defaults to 2 weeks it seems, though we made our own
that is valid for 2 months.  But this has resulted in our OCSP responders no
longer having valid signing certificates for the old CA cert.  I'm not sure
how anyone is supposed to support this situation.

openssl does allow you to explicitly mark a certificate as trusted for OCSP
signing with  X509_add1_trust_object(), but it appears that freeradius does
not support doing this.

Orion

-- 
Orion Poplawski
he/him/his  - surely the least important thing about me
Manager of IT Systems                      720-772-5637
NWRA, Boulder Office                  FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4087 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20241209/7a05143e/attachment-0001.bin>