Trouble with OCSP

[Orion Poplawski]

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

What is the expected relationship between ca_file and ca_path?  In the 
docs for ca_file there is this:

If ca_file is not used, then the certificate_file MUST include not only 
the server certificate, but ALSO all of the CA certificates used to sign 
the server certificate.

which led me to believe that it is needed since I didn't have the CA 
cert in the certficate_file.

The comments in the config file says:


                 #  ALL of the CA's in this list will be trusted
                 #  to issue client certificates for authentication.
                 #
                 #  In general, you should use self-signed
                 #  certificates for 802.1x (EAP) authentication.
                 #  In that case, this CA file should contain
                 #  *one* CA certificate.

Which seems a little contradictory - why say "all of the CA's" if it is 
only expected to contain one?  Why can't it contain more than one?

It appears that if ca_file is specified, ca_path is not used.  It 
doesn't seem like this is explicitly stated in the docs.  Is this expected?

Thanks.

-- 
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager                         720-772-5637
NWRA, Boulder/CoRA 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/20241204/cd73a84a/attachment-0001.bin>