As a system administrator, I want FreeIPA to accept OCSP GET requests so that CRL checks from Windows infrastructure work.
I have a Windows Remote Desktop Services RDS farm and need to use FreeIPA for the public key infrastructure. Currently CRL checks do not seem to be working. POST requests seem to be working, but the RDS client seems to be sending a GET request which is then returning a 404.
FreeIPA does not seem to support OCSP GET requests for CRL checks.
I created a SAN certificate and had it installed on member Windows servers in an RDS farm. Subsequent requests for CRL checks are GET requests and produce a 404 error.
Remote Desktop on Windows client says it cannot get the CRL list.
No errors presented at all.
ipa-server-4.5.0-21.el7.centos.1.2.x86_64 ipa-client-4.5.0-21.el7.centos.1.2.x86_64 389-ds-base-1.3.6.1-19.el7_4.x86_64 pki-ca-10.4.1-13.el7_4.noarch krb5-server-1.15.1-8.el7.x86_64
The RDS servers are running Windows Server 2016. The clients connecting to the RDS servers are Windows 7, 8, and 10.
Apache access log: <INTERNAL_IP> - - [06/Nov/2017:16:35:58 -0600] "GET /ca/ocsp/MEIwQDA%2BMDwwOjAJBgUrDgMCGgUABBTOLz9VStONUro%2FDV2p%2Fthry40UEQQU9sHVM9cnPTcYlyIaEHgn1CAKzsgCAXs%3D HTTP/1.1" 404 298 "-" "Microsoft-CryptoAPI/6.3"
Metadata Update from @frenaud: - Issue set to the milestone: Future Releases
Christina Fu pointed me to https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.0/html/Admin_Guide/OCSPRequests-GETMethod.html
According to my tests with freeipa-server-4.6.1-3.fc27.x86_64 and pki-ca-10.5.1-1.fc27.noarch, OCSP GET requests are working out of the box:
Dump server cert to file $ openssl s_client -connect $(hostname -f):443 > /tmp/cert.pem Create OCSP request $ openssl ocsp -issuer /etc/ipa/ca.crt -cert /tmp/cert.pem -reqout /tmp/ocsp-req.der Send OCSP request as base64 encoded GET request $ curl http://$(hostname -f)/ca/ocsp/$(base64 -w0 /tmp/ocsp-req.der) --output /tmp/ocsp-resp.der Decode response $ openssl ocsp -respin /tmp/ocsp-resp.der Response verify OK $ openssl ocsp -respin /tmp/ocsp-resp.der -text OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: O = IPA.TEST, CN = OCSP Subsystem Produced At: Nov 20 20:40:44 2017 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 5101BBCF83997A4F97331612AA38937F3A566DC1 Issuer Key Hash: 07DC7DC44937DB12AA5FB117F8918E1626DF1962 Serial Number: 09 Cert Status: good This Update: Nov 20 20:40:44 2017 GMT Response Extensions: OCSP Nonce: 041002E583F43C8A6B46D2AFCCDB7B8504DC
Thank you, cheimes for taking the time to look into this.
It appears that it is (and was) working afterall. Apologies. Our issue seemed to have something to do with accessing the resource using the wrong name, a name not on the signed certificate.
Why we got the error we did is beyond me, but seemed to be rather misleading.
Again, thank you for your time. This can be closed since all is in fact working.
mpetey, thank you for the update. Closing the issue per user agreement.
Metadata Update from @frenaud: - Issue close_status updated to: worksforme - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.