pfSense Certificate Manager's Revocation list (CRL) is unavailable
-
I am in the process of setting up Hyper-V Replication between two Windows servers. In this scenario each server requires a server certificate.
- I imported my CA certificate placing into the Windows Trusted Certificate Authorities folder.
- I then created a certificate in pfSense for the first server.
- Next, I imported the server certificate installing it into the Local Machine Personal certificate store.
- Everything looks fine with the certificates in Windows. The Windows Certificate Manager reports the server certificate is valid.
However, this error is raised when the Hyper-V client attempts to validate the certificate:
The interesting text is "Error: The revocation function was unable to check revocation for the certificate. (0x80092012)" The certificate has been selected and it has the correct properties. I believe the revocation check is the last step before accepting the certificate.
I have been trying to figure out why this is occurring for a couple of hours and need some help. I have a Revocation List defined for my CA but the Windows machine can't seem to find it. Does the pfSense Certificate Manager actually publish the list, or is the list only available to pfSense hosted services? If I read correctly, OpenVPN has some special settings to select a revocation list. The logic for that eludes me.
I tried adding a static Host Override entry for "my_CA_Name.mydomain" to the DNS Resolver in the hopes it's a DNS location problem but it had no effect.
Any help you might give will be greatly appreciated.
-
@bigtfromaz no the crl you create in pfsense wouldn't be published anywhere.. You could export it and do with it what you will.
You could always add cRLDistributionPoints to the CA cert with openssl, but its been so long since I have done something like that you would have to look up the particulars.
Might be a nice feature add to the Cert Manager..
-
The certificate contains the URL(s) of the CRL distribution point, or (OCSP URL, which one depends on the CA). Look at the details of the certificate to get that URL, which is the location that your client needs to access in order to check revocation. Then you can see if your client connect to that location.
If it uses CRL distribution point, the revocation check can fail if the client cannot connect to the CRL URL, or it can also fail if the CRL is returned, but expired. You can fetch the CRL in a browser and look at the dates to see if it is there, and if it 'expired'. The 'expiration' is usually labeled called 'Next Update' .
-
@johnpoz Thank you for the response. It's greatly appreciated. It will keep me from wasting more time. For now, I'll spin up a new Linux box and set up something there.
My first reaction to your feature idea was muted. After all, if no one has asked yet, then maybe it's not needed, but...
I spent a little time reviewing options and there aren't a lot of good ones out there. The Windows CA is cumbersome and costly. I really don't want another VM. I chose to try the Certificate Manager because it's straight forward, easy to use and running in a place I already maintain. Adding CRL capability would improve security and expand the pfSense value proposition, at least for SMBs.
-
@BassStation70 I confirmed the information provided by @johnpoz . The pfSense Certificate Manager does not add a CRL distribution point to the certificates it signs. In the absence of that, strict clients will not respect the certificate. In my use case I have to stand up a CA elsewhere.
-
@bigtfromaz said in pfSense Certificate Manager's Revocation list (CRL) is unavailable:
In my use case I have to stand up a CA elsewhere.
Not necessarily you can add the distribution point to the cert, and publish the exported crl there. just because the gui does not provide the means to add that, doesn't mean it can't be added with a simple openssl cmd.
-
@bigtfromaz If you generate your own CRL , be aware that the default length of the CRL itself in openssl is 30 days (or so I'm told...). You'll need to generate and re-publish a new CRL periodically, based on the number of days you choose for the CRL expiration. There is an option in openssl under 'openssl ca -gencrl -crldays ### ...' to explicitly set that value.
The trade-off is security vs. convenience. In a controlled environment with few certs and minimal turn-over, a longer period for the CRL expiration should be fine. I would do this at home to deal with a finicky "client". If you go with a shorter time period, consider automating the generation and publishing of CRLs based on the expiration you choose.
-
@johnpoz I stand corrected. I should have said stand up a CRL Server. The client needs to fetch the CRL in order to check revocations. The Root cert does not need to define a distribution point, although I suspect it is allowed. It is trusted by virtue of being in the client's Trusted Root CA folder. Anything signed by the root cert or its children, i.e., Intermediate CA certs, should offer a CRL distribution point. I saw this when I set up a Windows Certificate Server. That server automates the entire process. But it's overkill for my needs.
A good enhancement for pfSense would be to facilitate the definition of CRL distribution points in the GUI and serve up the CRL from pfSense. I suspect the latter would be the challenging part.
@BassStation70 The advice is appreciated and I think I now know enough to cobble some scripts together to create the CA contents and CRL using OpenSSL. I think Nginx can be used to distribute the CRL. Will hopefully package it as a Docker image so I can spin it up on an existing host.
Thank you both for your help.
-
@bigtfromaz said in pfSense Certificate Manager's Revocation list (CRL) is unavailable:
The client needs to fetch the CRL in order to check revocations.
Very true - can you not just place the crl on this machine running hyper-v, or can you not just disable the check.. if you look at the properties of any CA in the systems store, you should be able to add a url or disable it.
-
@johnpoz I just tried disabling on the root cert and the server certificate. No change in behavior. I am wondering if the checkbox indicates to use OCSP only. In other words, the CRL is not tried but no OCSP URL you still get the same error. Adding an additional CRL endpoint might be useful but I'm not seeing it in the properties.
-
@johnpoz to answer your first question, it won't change anything. At this point there is no CRL endpoint defined in the server certificate so the client isn't even trying to connect to the CRL server. So I am now believing that unable to check revocation for the certificate mean just that. It's unable because it doesn't know where to begin.
-
@bigtfromaz Did you try disabling this in the Certificate store which the particular client uses for it's trusted root. As I understand it, this setting will only indicate a different behavior to the clients who use that specific certificate store. If you made the change in Current User as yourself, it will only affects clients that you run. If you want to have this change behavior of another user, run the mmc as that user or else update the 'Local Computer' certificate store on the device (requires admin privilege) where the picky client is running. I don't know how it will behave in your particular case, but I'm pretty sure it matters where you make the change.
-
@bigtfromaz what about this
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /fQuick google about hyper-v replication and the check seems to point to turning off the check in the registry.
DisableCertRevocationCheck
Description: Hyper-V Replica supports certificate based mutual authentication, which allows the primary server to connect to the replica server over HTTPS. When establishing this connection, as part of validating the certificate, Hyper-V Replica checks if the issuing Certificate Authority (CA) has revoked the certificate.
However, due to deployment restrictions, this check would fail if the certificate revocation list (CRL) distribution point (CDP) is inaccessible. The check would also fail if self-signed certificates (generated using makecert) were used in lab deployments. Administrators can work around this restriction by setting this key.
Supported Values: 0, 1
Input interpretation:
0: Certificate revocation check is enabled
1: Certificate revocation check is disabled Default value: 0Primary/Replica server: This key can be set in both the primary and replica servers as required.
-
@BassStation70 I made the change to the Local Computer store. It's Hyper-V logging on as Local System. Hyper-V is showing the cert to me beforehand and it's using the correct certificate. I may be able to find a setting, group policy or registry hack and get windows to bypass the check.
In any event, we have drifted off topic as it relates to pfSense. I'll post again for edification after I sort it out.
-
@johnpoz well..as I was postulating my last response you were off doing my work for me! I'll give it a shot.
-
@bigtfromaz hehe - when I get curious about something, if not a simple fix - I look for other ways to skin the cat ;)
-
@johnpoz And the certificate has been accepted. You gotta love Microsoft. Why not just expose it in the configuration dialog?
-
@bigtfromaz said in pfSense Certificate Manager's Revocation list (CRL) is unavailable:
Why not just expose it in the configuration dialog?
Well they prob want you to use certs from their CA, etc. But yeah I hear yeah..
But then - this would of never been brought up, and I wouldn't of learned something new ;) Part of the reason I have stuck around here for so long and love helping people. Is helping someone figure out something almost always leads to people on both sides of the problem learning something..
And it brings up a possible feature request to expose being able to add a crl distribution uri in the gui, which would be win everyone using pfsense cert manager for more than just openvpn ;) or the webgui of pfsense. I use it for all my local certs.. I have not run into needing to publish the crl, but I can see how it would be a bonus addition to the cert manager. Even if not hosting the crl off pfsense, but just being able to easy add the uri for the distribution point.
