-----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. 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 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. - -- kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlXXHWYACgkQDC186MBRfrpgwwCeOZnRngPQQupSjb4A8ZnZOyua 0OQAn2fjW04b0QaB5k0SPQm16iGqbXPm =6btd -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
