On 21-08-2015 13:45, David Sommerseth wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 21/08/15 11:55, Rui Santos wrote: >> On 20-08-2015 18:40, David Sommerseth wrote: On 20/08/15 19:11, >> debbie...@gmail.com wrote: >>>>> ----- Original Message ----- From: "Rui Santos" >>>>> <rsan...@grupopie.com> To: >>>>> <openvpn-users@lists.sourceforge.net> Sent: Thursday, August >>>>> 20, 2015 3:10 PM Subject: Re: [Openvpn-users] CRL and >>>>> --CApath usage >>>>> >>>>> >>>>>> On 20-08-2015 15:01, debbie...@gmail.com wrote: >>>>>>> ----- Original Message ----- From: "Rui Santos" >>>>>>> <rsan...@grupopie.com> To: >>>>>>> <openvpn-users@lists.sourceforge.net> Sent: Thursday, >>>>>>> August 20, 2015 12:33 PM Subject: [Openvpn-users] CRL and >>>>>>> --CApath usage >>>>>>> >>>>>>> >>>>>>>> I'm using --CApath option for CA and CRL >>>>>>>> approving/checking >>>>>>>> >>>>>>>> I just revoked a certificate, copied the new CRL to >>>>>>>> CApath, overwriting the old one, and the OpenVPN >>>>>>>> allowed > the connection with that certificate. >>>>>>>> >>>>>>>> The openssl command for this: ~# openssl verify >>>>>>>> -crl_check -CApath <cadir>Â cert.crt error 23 at 0 >>>>>>>> depth lookup:certificate revoked >>>>>>>> >>>>>>>> I tried to connect several times, with success, which >>>>>>>> I shouldn't be able to. >>>>>>>> >>>>>>>> However, if I restart the OpenVPN service, it works as >>>>>>>> expected, with the error: <IP>:42410 VERIFY ERROR: >>>>>>>> depth=0, error=certificate revoked: C=........ >>>>>>>> Directories leading to CApath and files are accessible >>>>>>>> to all user: 0755/0644 >>>>>>>> >>>>>>>> I wonder if there is any kind of bug on this. Is this >>>>>>>> an expected behavior ? One should not need to restart >>>>>>>> the OpenVPN instance, just to reread the CRL. >>>>>>>> >>>>>>>> Am I missing something ? >>>>>>> The manual has this to say: >>>>>>> >>>>>>> Note: As the crl file (or directory) is read every time a >>>>>>> peer connects, if you are dropping root privileges with >>>>>>> --user, make sure that this user has sufficient >>>>>>> privileges to read the file. >>>>>> Hi Debbie, >>>>>> >>>>>> I'm aware of that. OpenVPN is indeed running as user >>>>>> nobody. But the accesses 0755/0644 for directories and >>>>>> files, respectively, should take care of that issue, >>>>>> shouldn’t it ? >>>>> Did you try *without* dropping root orivileges ? >> Nonsense. If files and directories have 0655/0744, even the >> 'nobody' user should be able to read these files. Also consider >> that *connecting* to the server DO work. >>> @Debbie Nonetheless, thank you for your effort. I do appreciate >>> you help. >> >>>>> Perhaps the crl (in PEM format) is also effected by >>>>> --persist-key ... >> This is just pure guesswork, debbie10t. The CRL file is *NOT* >> affected by --persist-key. >> >> >> Rui: How have you configured --crl? Did you add the 'dir' flag >> when pointing to the directory? Or did you point directly to a CRL >> file? >>> Hi David, >>> I assume you mean the --crl-verify option, right? If so, the >>> --crl-verify option is not specified at all. According to man >>> page, on the --crl-verify section, the you can either specify a >>> CRL PEM encoded file, which contains one or more CRLs >>> concatenated. This could be doable. With the dir flag, the >>> directory you specify as second parameter, must contains files >>> named after the serial numbers of the "revoked" certificates. >>> Quoting from the man page: "If the optional dir flag is >>> specified, enable a different mode where crl is a directory >>> containing files named as revoked serial numbers (the files may >>> be empty, the contents are never read). If a client requests a >>> connection, where the client certificate serial number >>> (decimal string) is the name of a file present in the directory, >>> it will be rejected." According to my understanding, you cannot >>> have multiple CRLs in one dir, by using --crl-verify dir <dir> >>> approach. Do you agree ? > Yes, I meant the --crl-verify option, sorry about the misguiding here. > And you're right, using the 'dir' option doesn't take CRL files but > empty files with the file names being certificate serial numbers of > revoked certificates. The contents of these files in this 'dir' case > is never parsed. > >>> Nonetheless, IMHO, the use of capath is preferable, because use >>> just need to place both CAs and CRLs files in one directory, >>> c_rehash it, and that's all... all you need to do to manage it, >>> is to copy the CRL across, whenever a certificate is revoked. In >>> my case it would also be preferable, because there are multiple >>> CAs and CRLs, thus I would not need it to concatenate all CRLs, >>> every time a CRL is changed. That's why I would prefer the >>> capath. > Jan Just Keijser is truly the authority when it comes to configuring > OpenVPN, which also responded to you. I double checked a few details > with his "OpenVPN 2 Cookbook", and I relearned some details about > - --capath I had forgotten. Hi again David,
Thanks for the heads up :) I was unaware of that... I'm kind of new on this list. My first reply on this list was actually his, 9 days ago... Thanks Jan. > > So, you can use --capath for CA certificates and their corresponding > CRL. But there are a few tweaks here, so if you can double check that > your CRL files inside the CApath directory have the same hash as the > CA hash they represent, but with an .r0 extension instead of .0. That > should normally be the trick. > > I hope JJK doesn't kill me for pulling out an extract of one example > of his book: > > $ cd /path/to/ca/directory > $ openssl x509 -hash -noout -in ca.crt > bcd54da9 > > This means that the CA file should be named bcd54da9.0 and the CRL > file should be named bcd54da9.r0 I'm aware of that. On most Linux distributions, you may replace that with the following command: ~# c_rehash . It will perform all those hashes and some more. I've double checked, and c_rehash generates the same hashes that the standard OpenSSL command generates, including for the CRLs with .r0 ones. However it will also generate other links/hashes pointing to the same CAs and SubCAs. I'm unaware what those are for... But, since I do not use the --ca nor the --verify-crl options (only the --capath), OpenVPN would not even work nor read the CRLs upon restart, right ? > > If this is the situation in your setup, I'd wait for JJK to test this > out as well. If it turns out there's a bug or misconfiguration, he > will usually be able to confirm it. Ok. Let's let him enjoy the rest of his vacations. :) I'll wait. David, once again, thanks for your and time spent on this. > > > - -- > kind regards, > > David Sommerseth > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlXXHWYACgkQDC186MBRfrpgwwCeOZnRngPQQupSjb4A8ZnZOyua > 0OQAn2fjW04b0QaB5k0SPQm16iGqbXPm > =6btd > -----END PGP SIGNATURE----- > > -- Melhores Cumprimentos / Best Regards, Rui ------------------------------------------------------------------------------ _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
