IPsec - Intended mechanism of CRL check
-
You obviously need unauthenticated access to the CRL location. Fix your CA.
-
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-peerTherefore I am currently out of ideas and do appreciate any further ideas. Regards, Peter -
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.
-
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 -
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.)
-
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 -
You obviously should have a proper public IP for the webserver on the public nameservers (WAN). It should resolve to LAN address on LAN.
-
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 -
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.)
-
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