IPsec - Intended mechanism of CRL check

pvoigt

I like the concept of certificate based authentication and I am particularly using it with FreeRadius (not on pfSense) and OpenVPN since pfSense 2.0.1. I am currently running pfSense 2.2-RELEASE (nanoBSD, i386).

Recently I have started to get some practise with IPsec, at least motivated by pfSense supporting IKEv2. After struggling with the Windows 7 built-in IKEv2 client for some time I have finally managed to connect using EAP-TLS.

With FreeRadius I have to manually install the CRL in the configuration directory. While the pfSense webGUI offers explicit CRL check for OpenVPN there is no such option with IPsec. I am operating my own CA with all issued certificates carrying information about the CRL distribution point.

What is the intended way of pfSense/StrongSwan to obtain information about CRL?

I have studied the logfile of StrongSwan and have seen that during the certificate check procedure there was an attempt to fetch the CRL of my CA. But this was not successfull although the logged URL is correct.

Is the automatic fetching of CRL the way to go or can/should I manually install the CRL. If the automatic fetching is intended: How can I check, why it is not successful?

Regards,
Peter

eri--

Well strongswan tries to do that automatically.
Meaning it will read the attributes of you CA and extract the link from it and try to reach that url to download the CRL.
If it does not succeed it skips it.

What you need to make sure is that pfSense can fetch the CRL file from the link in the CA to work.

pvoigt

That's what I have supposed, thanks for confirmation. However, I do not have attributes of the CRL download link in my CA certificate but in each issued certificate instead. I don't know, if the CRL download link should better be in the CA certificate.

Nevertheless, I can see in the logs that StrongSwan tries to download my CRL but fails with


...
charon: checking certificate status of "C=XXX, ST=XXX, O=XXX, OU=XXX, CN=XXX"
charon: 14[CFG]   fetching crl from '<my_http_crl_uri>' ...
charon: 14[CFG] crl fetching failed
...</my_http_crl_uri>

where I blanked out my certificate data with "XXX" and subsequently my CRL URI with <my_http_crl_uri>.

If I manually issue the commands:


cd /var/etc/ipsec/ipsec.d/crls
fetch

I obtain the following error:
Certificate verification failed for /C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address


675215676:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/usr/pfSensesrc/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:1162:
fetch: <my_http_crl_uri>: Authentication error</my_http_crl_uri>

On the other hand, I can download my CRL with the same URI on any machine in my network e.g. using wget or curl.

What does the error mean and why is pfSense not able to download my CRL? Where do these specific certificate attribute values come from, e.g. L=Somecity, O=CompanyName etc.?

Regards,
Peter</my_http_crl_uri>

eri--

It means that the CA is not trusted by fetch and i guess even by strongswan.

A test would be to put the ca under the /var/etc/ipsec/ipsec.d/ca and see if that fixes it.

pvoigt

@ermal:

It means that the CA is not trusted by fetch and i guess even by strongswan.

A test would be to put the ca under the /var/etc/ipsec/ipsec.d/ca and see if that fixes it.

Hhm, I am astonished why fetch is caring at all about the trust state of a file to be fetched. As far as I have understood fetch, it is comparable to wget or curl and both programs do not care about the trust state of a CRL to be fetched - they just fetch files.

If I manually create the CRL file, what is the right file name, or doesn't it matter? Is there a fetch alternative available on pfSense, because fetch refuses to fetch a CRL file?

Even if I will be successful to manually create the CRL file, there is still some misconception in the interaction of pfSense and StrongSwan: The CA that is not trusted by StrongSwan is regulary imported into the pfSense certificate manager, e.g. it is trusted by pfSense and services like OpenVPN and CaptivePortal.

And even more strange: If I issue

ipsec listcacerts

my CA is listed as expected.

Regards,
Peter

pvoigt

Well, here's some more information:

I have manually created a CRL file as/var/etc/ipsec/ipsec.d/crls/<cacert_file_base_name>.crl</cacert_file_base_name>in PEM format and issued```
ipsec rereadcrls && ipsec listcrls


To be done:

*   Check log file of a mobile client login process, if any CRL related errors still occur.

*   Check, if CRL can be auto-updated by StrongSwan.

Regards,
Peter

pvoigt

Finally checked the behavior, when a mobile client connects. The CRL error remains, e.g. on connect the server tries to download the CRL with fetch which fails with the above "Authentication error". Therefore I would like to clarify, if

there is something special with my cert or CRL
others have the same issue

Regards,
Peter

doktornotor

You obviously need unauthenticated access to the CRL location. Fix your CA.

pvoigt

@doktornotor:

You obviously need unauthenticated access to the CRL location. Fix your CA.

That was my first conclusion as well. But I verified that the location does not require authentication. Every machine inside and outside my LAN can download the CRL with the very same URL without any authentication. But when sitting on the pfSense machine and issuing the corresponding fetch command I obtain the above error.

I have investigated this in more detail and I strongly suppose it is a NAT reflection related issue. Although I have no problems to access the CRL URL (which is a public address) from machines inside my LAN, I cannot access it on the firewall via fetch. As soon as I change the FQDN with the LAN IP address, fetching the CRL from the firewall works as expected. Only the public address fails.

I have checked the above mentioned attribute values of the failed fetch command: The belong to the pfSense pre-generated webGUI certificate. This finally makes me conclude that my issue is related to NAT reflection, which otherwise seems to work correctly.

And the openssl waring is clear now also: It is a complaint about the certificate subject not matching hostname. I found this with```
fetch -v --no-verify-peer


Therefore I am currently out of ideas and do appreciate any further ideas.

Regards,
Peter

doktornotor

Your firewall should resolve the FQDN to the LAN IP address since it's sitting on LAN (split DNS/host overrides or whatnot.) Also, this obviously should NOT sit on HTTPS, horrible idea.

pvoigt

@doktornotor:

Your firewall should resolve the FQDN to the LAN IP address since it's sitting on LAN (split DNS/host overrides or whatnot.) Also, this obviously should NOT sit on HTTPS, horrible idea.

To be more specific: The CRL URL is a public address and NOT a LAN address. I have currently activated NAT reflection and it is working otherwise as expected. Only when sitting on the firewall NAT reflection seems to fail.

The CRL URL is HTTP and not HTTPS. I have created an Apache rewrite expception for the CRL URL, because all traffic is redirected to HTTPS to protect the password protected locations. I will temporarily disable HTTPS rewrite completely to see, if this might be the reason, and report back.

Regards,
Peter

doktornotor

@pvoigt:

To be more specific: The CRL URL is a public address and NOT a LAN address.

Dude, that is the problem! When the webserver serving the CRLs is sitting on LAN, then its FQDN should NOT resolve to the public IP on the firewall. (And yeah, there should not be any HTTPS rewrites for this.)

pvoigt

@doktornotor:

@pvoigt:

To be more specific: The CRL URL is a public address and NOT a LAN address.

Dude, that is the problem! When the webserver serving the CRLs is sitting on LAN, then its FQDN should NOT resolve to the public IP on the firewall. (And yeah, there should not be any HTTPS rewrites for this.)

I have supposed so but was unsure - thank you very much for confirming this. For a IPsec gateway that has to check mobile client certificates using CRL information it makes sense to provide the crlDistributionPoints as a LAN FQDN in the client certificate. The webserver serving the CRL is indeed sitting on LAN and can be reached via HTTP only, e.g. the HTTP->HTTPS rewrite exception for the CRL URL is working as expected: No certificate warning at all.

May be I do not fully understand the concept of certificates: Doesn't the situation change for a whatever client connecting to my pulbic webserver? I suppose the client uses the CRL information to assure he is seeing a valid server certificate. And this client needs of course a public CRL address. Could you please correct or confirm?

Regards,
Peter

doktornotor

You obviously should have a proper public IP for the webserver on the public nameservers (WAN). It should resolve to LAN address on LAN.

pvoigt

@doktornotor:

You obviously should have a proper public IP for the webserver on the public nameservers (WAN). It should resolve to LAN address on LAN.

OK, if I understand you correctly, the CRL information in each issued certificate, e.g. server and client certificate, should carry a public FQDN. I just have to configure my DNS forwarder that this public FQDN resolves to the corresponding LAN IP address.

To be honest: Until now I did not use the DNS forwarder at all. I have thought: Why to use if NAT reflection works as expected. But I have just configured it correspondingly and my initial StrongSwan issue is solved.

And once again: Thank you very much for your assistance.

Regards,
Peter

doktornotor

Uhm… yes, this URL needs to be reachable (at least ONE of them since you can embed multiple revocation check mechanisms into the certificate) from WAN if those certificates are supposed to be used elsewhere. Now, of course you could have an internal one there as well that never resolves for clients on WAN, it's just gonna get skipped and the others tried instead.) However, that'd clearly require re-issuing the current certificates. (Plus, need to make sure the webserver is going to respond on all of those FQDNs.)

pvoigt

Yeah, thanks for grasping this former question. Currently, everything is working as expected with the help of a correspondingly configured DNS forwarder. But I consider adding to future certificates two CRL URLs: One with a public address and one with a LAN address. I have just spent some time to re-issue most of my certificates due to expiry range 1 year and I am glad not being forced to do it again although those certificates do just protect my ambitious home LAN ;)

Regards,
Peter