OpenVPN + wrong CRL shown - revoking Certs doesn't work in all cases

Nachtfalke

Hi,

I created a CA, some Certs and I setup an OpenVPN Server. Everything works fine.
In the OpenVPN Server config I added an "Certificate Revocation List" which I created before.
I could add there a certificate which I wish to revoke and this works. The client couldn't reconnect anymore and the OpenVPN Syslog tells me

openvpn[54799]: 12.13.14.15:55958 TLS_ERROR: BIO read tls_read_plaintext error: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned

Fine.

Now I canceld the revoke of this certificate, but the client couldn't reconnect. The system log output is the same as above. I tried restarting the OpenVPN server but no success.

Further, if the CRL is empty, then there isn't an "edit" button to add other certificates. This is only working after creating a CRL the first time, adding a Cert to revoke, cancel the revoke and then no edit button.

My third problem is, that the OpenVPN server config shows me old CRL which do not exist anymore.

I attached three pictures, please let me know if you need more information or if I am wrong in some understanding of OpenVPN CRLs.

1.JPG_thumb

2.JPG_thumb

3.JPG_thumb

jimp

Are those old CRLs from CAs you have deleted?

I suppose having a CRL there that had no certificates is what made it think it was imported. I'll have to re-check the code and see if there is another way that can happen. It doesn't let you edit in that case because you can't edit an imported CRL.

The problem is that you are working around an almost empty CRL… if you were adding or deleting a second certificate (or a third, fourth, etc) you probably wouldn't be seeing that same behavior.

Nachtfalke

@jimp:

Are those old CRLs from CAs you have deleted?

Could be possible. I did some testing with the Cert Manager in the past, creating, deleting and so on. Several new installations -som,etimes with defaul settings, sometimes with a backuped config.xml.
I'm not sure at all but I don't think I have deleted a CA in this config.xml file…

I suppose having a CRL there that had no certificates is what made it think it was imported. I'll have to re-check the code and see if there is another way that can happen. It doesn't let you edit in that case because you can't edit an imported CRL.

The problem is that you are working around an almost empty CRL… if you were adding or deleting a second certificate (or a third, fourth, etc) you probably wouldn't be seeing that same behavior.

Ok, this makes sense. Perhaps I will create a "fake" certificate and add this as revoked to the CRL so that I could edit it for future purposes.
Perhaps you could wirte a script which creates a fake cert when bulding a CRL but which is not visible in the GUI !?

But why couldn't I reconnect to the OpenVPN server after I canceled the certificate revokation ?

Thanks a lot!

jimp

Not sure why you couldn't connect offhand. I had disabled selecting CRLs with no certificates revoked before, OpenVPN may not like a blank CRL.

I just make a bunch of various cert/CRL fixes this afternoon, try a snapshot from tomorrow morning and see if you have any better luck.

Nachtfalke

Thank you very much.
I hope I could do some tests, too, with an additional certificate left in the CRL.

jimp

You'll have to clean out the old/invalid CRLs from your config by hand though, the new code wouldn't allow them to still exist but I don't want to delete them automatically.

Nachtfalke

Ok, will try this tomorrow.

Did a quick test now before I go to bed:

Created a new certificate, a new CRL and revoked a cert, restarted my openvpn server two times but could still connect.

I attached you 4 screenshots.

1.jpg_thumb

2.jpg_thumb

3.jpg_thumb

4.jpg_thumb

dynaguy

I am having the same problem.

running:
2.0-RC1 (i386)
built on Fri May 6 10:38:23 EDT 2011

jimp

So now you're saying that when you make a CRL and you revoke a cert, nobody can connect? Is the service even running? (Check Status > Services), Does the crl-verify file in /var/etc/openvpn/ for that instance have anything in it?

Nachtfalke

Hi,

1.) I didn't found time to test all scenarios but with snapshot May 7th there is an "edit" button for the CRL with no Certs in it. Great!

2.) After editing the config.xml and deleting the "empty" CRL, the blank entry in OpenVPN Server CRL pulldownmenu disapperead. Great!

Now I'm having another problem:
My CA is "HPA-CA". I created a new CRL called "MYCRL" and added this CRL to the OpenVPN Server config.
After doing this, the OpenVPN server is restarting and no unnormal entries in syslog or syslog openvpn.

But after doing this, I cannot connect to this OpenVPN server. Not error log on pfsense and this is the only thing on Windows OpenVPN Client:

Sun May 08 23:00:41 2011 OpenVPN 2.2.0 Win32-MSVC++ [SSL] [LZO2] built on Apr 26 2011
Sun May 08 23:00:41 2011 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Sun May 08 23:00:41 2011 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sun May 08 23:00:41 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sun May 08 23:00:41 2011 Control Channel Authentication: using 'pfsense1-UDP-1194-tls-RBS.key' as a OpenVPN static key file
Sun May 08 23:00:41 2011 LZO compression initialized
Sun May 08 23:00:41 2011 UDPv4 link local (bound): [undef]:1194
Sun May 08 23:00:41 2011 UDPv4 link remote: 11.12.13.14:1194

This is repeating every time the keepalive time is over.
If I delete the CRL "MYCRL" in the OpenVPN server config I can reconnect.

Further:
Why does the OpenVPN Server config display two CRL: "HPA-CA" which isnt a list, just the name of my CA and then the correct CRL called "MYCRL" ?

Thanks in advance!

1.jpg_thumb

2.jpg_thumb

jimp

Not sure why it wouldn't connect - it would help to know if you have any certificates revoked in that CRL, and either way it would help to know if /var/etc/openvpn/server<x>.crl-verify contained anything (where <x>is whatever this instance is).

As for that extra CRL entry, it may still be a side effect from hand editing your config, or something else that needs cleaned up.</x></x>

Nachtfalke

Hi,

like I said in my previous post:
I created a new CRL and a new Certificate. Then I revoked this certificate and then canceld the evoke - just to see, if the CRL is empty but with an edit button.
Now the CRL is empty - no revoked certificates in it.

The server2.crl-verify file is empty.

–edit--

This are the only both blocks with <crl>in my config.xml:

	 <crl><refid>4d401a4cb674f</refid>

		<caref>4d4018ea7d5dd</caref>
		<serial>10000</serial>
		<lifetime>9999</lifetime>
		<text>xxXXxxXXxx</text></crl> 
	 <crl><refid>4dc7030fca8f5</refid>

		<caref>4d445bf7f2a0c</caref>
		<serial>9999</serial>
		<lifetime>9999</lifetime></crl> 
```</crl>

jimp

That top one is probably from a CA you deleted before (note the caref doesn't match)

OpenVPN may not like a zero-byte crl. I'll have to poke at it some more.

Nachtfalke

I will try to do a complete fresh install of my pfsense to be sure to have no old code fragments in my config.

jimp

I made more improvements to CRL handling today, hopefully OpenVPN will be happy now, there will never be a 0-byte CRL file anymore.

Nachtfalke

Thanks jimp,

I hope I will find some time on weekend to test this.

Elodie

@jimp:

I made more improvements to CRL handling today, hopefully OpenVPN will be happy now, there will never be a 0-byte CRL file anymore.

Good news jimp !
Does that mean we can update our pfsense ?

jimp

It should be in snapshots by now.

Elodie

Great I'll try it tomorow or next week and I'll tell you !

Nachtfalke

Hi,

I did a test today with the CRL but with no success. With the snapshot from today there isn't an empty server2.crl-verify anymore, but there is still the problem that I could not connect to an OpenVPN server when I added there a CRL.

I didn't findeany time to do a complete reinstallation of my pfsense so this could be perhaps the problem.