Re: [strongSwan] pki --verify Command
Hi Jafar, > If I omit the crl option completely no crl check takes place as expected: Yes, that would require adding the --online option. The --crl option automatically does that. > The crl command line options forces a crl check but the locally provided > crl is completely ignored even though it is the same crl on the server. > Is that to be expected? I can't reproduce that, using the same hierarchy with two intermediate CAs: > using certificate "C=CH, O=strongSwan, CN=server" > using trusted intermediate ca certificate "C=CH, O=strongSwan, > CN=strongSwan ICA 2" > checking certificate status of "C=CH, O=strongSwan, CN=server" > using trusted intermediate ca certificate "C=CH, O=strongSwan, > CN=strongSwan ICA" > reached self-signed root ca with a path length of 0 > using trusted certificate "C=CH, O=strongSwan, CN=strongSwan ICA 2" > crl correctly signed by "C=CH, O=strongSwan, CN=strongSwan ICA 2" > crl is valid: until Feb 27 17:28:52 2018 > certificate was revoked on Feb 12 16:28:52 UTC 2018, reason: unspecified > using cached crl > certificate untrusted If I don't add the CRL but --online instead (without having uploaded the CRL) I get: > using certificate "C=CH, O=strongSwan, CN=server" > using trusted intermediate ca certificate "C=CH, O=strongSwan, > CN=strongSwan ICA 2" > checking certificate status of "C=CH, O=strongSwan, CN=server" > fetching crl from 'https://strongswan.org/test.crl' ... > crl fetching failed > certificate status is not available > using trusted intermediate ca certificate "C=CH, O=strongSwan, > CN=strongSwan ICA" > checking certificate status of "C=CH, O=strongSwan, CN=strongSwan ICA 2" > certificate status is not available > using trusted ca certificate "C=CH, O=strongSwan, CN=strongSwan CA" > checking certificate status of "C=CH, O=strongSwan, CN=strongSwan ICA" > certificate status is not available > reached self-signed root ca with a path length of 2 > certificate trusted, lifetimes valid, revocation checking failed And after uploading the CRL: > using certificate "C=CH, O=strongSwan, CN=server" > using trusted intermediate ca certificate "C=CH, O=strongSwan, > CN=strongSwan ICA 2" > checking certificate status of "C=CH, O=strongSwan, CN=server" > fetching crl from 'https://strongswan.org/test.crl' ... > using trusted intermediate ca certificate "C=CH, O=strongSwan, > CN=strongSwan ICA" > reached self-signed root ca with a path length of 0 > using trusted certificate "C=CH, O=strongSwan, CN=strongSwan ICA 2" > crl correctly signed by "C=CH, O=strongSwan, CN=strongSwan ICA 2" > crl is valid: until Feb 27 17:28:52 2018 > certificate was revoked on Feb 12 16:28:52 UTC 2018, reason: unspecified > certificate untrusted And without either option: > using certificate "C=CH, O=strongSwan, CN=server" > using trusted intermediate ca certificate "C=CH, O=strongSwan, > CN=strongSwan ICA 2" > using trusted intermediate ca certificate "C=CH, O=strongSwan, > CN=strongSwan ICA" > using trusted ca certificate "C=CH, O=strongSwan, CN=strongSwan CA" > reached self-signed root ca with a path length of 2 > certificate trusted, lifetimes valid Are you sure your local CRL is the same as that on the server? Could you perhaps send the certificates and CRLs in question? Regards, Tobias
Re: [strongSwan] pki --verify Command
Just to be clear, please note the behavior I described below is not limited to pki --verify dir, or even pki --verify. The daemon itself behaves the same way. It doesn't use the local crl if a url is embedded in the certificate itself. --Jafar On 2/12/2018 9:28 AM, Jafar Al-Gharaibeh wrote: Tobias, I've just tested the pki-verify-dirs branch, it works perfectly. Thank you again. I noticed when testing that if the certificate has a crl uri, pki verify only uses that even if I supply a --crl command option. pki --verify --in /etc/ipsec.d/certs/mars_revoked.crt --cacert=/etc/ipsec.d/cacerts/ --crl=/etc/ipsec.d/crls/crr.crl using certificate "C=US, O=ATC, CN=mars" using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster3" checking certificate status of "C=US, O=ATC, CN=mars" fetching crl from 'http://192.168.225.142/crls/crr.crl' ... crl fetching failed certificate status is not available using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster2" checking certificate status of "C=US, O=ATC, CN=CRRMaster3" certificate status is not available using trusted ca certificate "C=US, O=ATCorp, CN=CRRMaster" checking certificate status of "C=US, O=ATC, CN=CRRMaster2" certificate status is not available reached self-signed root ca with a path length of 2 certificate trusted, lifetimes valid, revocation checking failed If I place the the crl on the server, it works by pulling the crl directly from there: pki --verify --in /etc/ipsec.d/certs/mars_revoked.crt --cacert=/etc/ipsec.d/cacerts/ --crl=/etc/ipsec.d/crls/crr.crl using certificate "C=US, O=ATC, CN=mars" using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster3" checking certificate status of "C=US, O=ATC, CN=mars" fetching crl from 'http://192.168.225.142/crls/crr.crl' ... using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster2" reached self-signed root ca with a path length of 0 using trusted certificate "C=US, O=ATC, CN=CRRMaster3" crl correctly signed by "C=US, O=ATC, CN=CRRMaster3" crl is valid: until Feb 14 10:37:00 2018 certificate was revoked on Jan 15 16:37:16 UTC 2018, reason: affiliation changed certificate untrusted If I omit the crl option completely no crl check takes place as expected: pki --verify --in /etc/ipsec.d/certs/mars_revoked.crt --cacert=/etc/ipsec.d/cacerts/ using certificate "C=US, O=ATC, CN=mars" using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster3" using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster2" using trusted ca certificate "C=US, O=ATCorp, CN=CRRMaster" reached self-signed root ca with a path length of 2 certificate trusted, lifetimes valid The crl command line options forces a crl check but the locally provided crl is completely ignored even though it is the same crl on the server. Is that to be expected? Thank you in advance Jafar On 2/12/2018 8:43 AM, Jafar Al-Gharaibeh wrote: Hi Tobias, On 2/12/2018 8:34 AM, Tobias Brunner wrote: I did write a script that does that but I thought it is very inefficient since you have to sweep through CAs/CRLs with pki --print to figure out the correct chain in order to use them with pki --verify. You can just pass it all the CA certs/CRLs you (or rather the daemon) trust. Unless you have e.g. configs with CA cert constraints there is not really a need to pass the exact chain to figure out whether a certificate is valid and trusted by the daemon. Good to know! Thanks for letting me know abot pki-verify-dirs. Sounds like what I'm looking for. I wish I knew it exists before wasting time on scripting :-). It didn't, I quickly put that together this morning :-) Well, I initially assumed it did, but when I looked at the branches I have locally I didn't find it. I knew you've must just added it. thanks! :-) Is that branch going to be merged any time soon? Probably not with the upcoming release, but maybe the next one. Now that I know you've just added it, I see why it is not yet in! :-) Regards, Jafar
Re: [strongSwan] pki --verify Command
Tobias, I've just tested the pki-verify-dirs branch, it works perfectly. Thank you again. I noticed when testing that if the certificate has a crl uri, pki verify only uses that even if I supply a --crl command option. pki --verify --in /etc/ipsec.d/certs/mars_revoked.crt --cacert=/etc/ipsec.d/cacerts/ --crl=/etc/ipsec.d/crls/crr.crl using certificate "C=US, O=ATC, CN=mars" using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster3" checking certificate status of "C=US, O=ATC, CN=mars" fetching crl from 'http://192.168.225.142/crls/crr.crl' ... crl fetching failed certificate status is not available using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster2" checking certificate status of "C=US, O=ATC, CN=CRRMaster3" certificate status is not available using trusted ca certificate "C=US, O=ATCorp, CN=CRRMaster" checking certificate status of "C=US, O=ATC, CN=CRRMaster2" certificate status is not available reached self-signed root ca with a path length of 2 certificate trusted, lifetimes valid, revocation checking failed If I place the the crl on the server, it works by pulling the crl directly from there: pki --verify --in /etc/ipsec.d/certs/mars_revoked.crt --cacert=/etc/ipsec.d/cacerts/ --crl=/etc/ipsec.d/crls/crr.crl using certificate "C=US, O=ATC, CN=mars" using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster3" checking certificate status of "C=US, O=ATC, CN=mars" fetching crl from 'http://192.168.225.142/crls/crr.crl' ... using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster2" reached self-signed root ca with a path length of 0 using trusted certificate "C=US, O=ATC, CN=CRRMaster3" crl correctly signed by "C=US, O=ATC, CN=CRRMaster3" crl is valid: until Feb 14 10:37:00 2018 certificate was revoked on Jan 15 16:37:16 UTC 2018, reason: affiliation changed certificate untrusted If I omit the crl option completely no crl check takes place as expected: pki --verify --in /etc/ipsec.d/certs/mars_revoked.crt --cacert=/etc/ipsec.d/cacerts/ using certificate "C=US, O=ATC, CN=mars" using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster3" using trusted intermediate ca certificate "C=US, O=ATC, CN=CRRMaster2" using trusted ca certificate "C=US, O=ATCorp, CN=CRRMaster" reached self-signed root ca with a path length of 2 certificate trusted, lifetimes valid The crl command line options forces a crl check but the locally provided crl is completely ignored even though it is the same crl on the server. Is that to be expected? Thank you in advance Jafar On 2/12/2018 8:43 AM, Jafar Al-Gharaibeh wrote: Hi Tobias, On 2/12/2018 8:34 AM, Tobias Brunner wrote: I did write a script that does that but I thought it is very inefficient since you have to sweep through CAs/CRLs with pki --print to figure out the correct chain in order to use them with pki --verify. You can just pass it all the CA certs/CRLs you (or rather the daemon) trust. Unless you have e.g. configs with CA cert constraints there is not really a need to pass the exact chain to figure out whether a certificate is valid and trusted by the daemon. Good to know! Thanks for letting me know abot pki-verify-dirs. Sounds like what I'm looking for. I wish I knew it exists before wasting time on scripting :-). It didn't, I quickly put that together this morning :-) Well, I initially assumed it did, but when I looked at the branches I have locally I didn't find it. I knew you've must just added it. thanks! :-) Is that branch going to be merged any time soon? Probably not with the upcoming release, but maybe the next one. Now that I know you've just added it, I see why it is not yet in! :-) Regards, Jafar
Re: [strongSwan] pki --verify Command
Hi Tobias, On 2/12/2018 8:34 AM, Tobias Brunner wrote: I did write a script that does that but I thought it is very inefficient since you have to sweep through CAs/CRLs with pki --print to figure out the correct chain in order to use them with pki --verify. You can just pass it all the CA certs/CRLs you (or rather the daemon) trust. Unless you have e.g. configs with CA cert constraints there is not really a need to pass the exact chain to figure out whether a certificate is valid and trusted by the daemon. Good to know! Thanks for letting me know abot pki-verify-dirs. Sounds like what I'm looking for. I wish I knew it exists before wasting time on scripting :-). It didn't, I quickly put that together this morning :-) Well, I initially assumed it did, but when I looked at the branches I have locally I didn't find it. I knew you've must just added it. thanks! :-) Is that branch going to be merged any time soon? Probably not with the upcoming release, but maybe the next one. Now that I know you've just added it, I see why it is not yet in! :-) Regards, Jafar
Re: [strongSwan] pki --verify Command
Hi Jafar, > I did write a script that does that but I thought it is very inefficient > since you have to sweep through CAs/CRLs with pki --print to figure out > the correct chain in order to use them with pki --verify. You can just pass it all the CA certs/CRLs you (or rather the daemon) trust. Unless you have e.g. configs with CA cert constraints there is not really a need to pass the exact chain to figure out whether a certificate is valid and trusted by the daemon. > Thanks for > letting me know abot pki-verify-dirs. Sounds like what I'm looking for. > I wish I knew it exists before wasting time on scripting :-). It didn't, I quickly put that together this morning :-) > Is that branch going to be merged any time soon? Probably not with the upcoming release, but maybe the next one. Regards, Tobias
Re: [strongSwan] pki --verify Command
Hi Tobias, On 2/12/2018 6:37 AM, Tobias Brunner wrote: Hi Jafar, 2- "pki --verify --in certfile " change it to use the "default" trust store if no additional arguments are supplied There is no "default" trust store. It very much depends on the configuration backend used by the daemon from where certificates are loaded automatically (if at all). I understand the limitation here, that is why I quoted "default" Independent of the first choice above, we can add new commands line options to point to the paths of where CA/crls are stored: 3-"pki --verify --in certfile --capath path-to-ca's --crlpath path-to-crls 4-Or we can change existing options --cacert and --crl such the if the supplied argument is a directory we treat them as such and load whatever CA's CRLs needed for verification. Both are simple enough to implement, the latter can be found in the pki-verify-dirs branch. I guess you could also just wrap calls to pki --verify with a script and add --cacert/crl arguments as appropriate (then you'd have more control if the CA certs and CRLs are e.g. stored in the same directory with different file extensions). I did write a script that does that but I thought it is very inefficient since you have to sweep through CAs/CRLs with pki --print to figure out the correct chain in order to use them with pki --verify. Thanks for letting me know abot pki-verify-dirs. Sounds like what I'm looking for. I wish I knew it exists before wasting time on scripting :-). Is that branch going to be merged any time soon? Cheers, Jafar
Re: [strongSwan] pki --verify Command
Hi Jafar, > 2- "pki --verify --in certfile " change it to use the "default" trust > store if no additional arguments are supplied There is no "default" trust store. It very much depends on the configuration backend used by the daemon from where certificates are loaded automatically (if at all). > Independent of the first choice above, we can add new commands line > options to point to the paths of where > CA/crls are stored: > 3-"pki --verify --in certfile --capath path-to-ca's --crlpath path-to-crls > > 4-Or we can change existing options --cacert and --crl such the if the > supplied argument is a directory we treat them as such and load whatever > CA's CRLs needed for verification. Both are simple enough to implement, the latter can be found in the pki-verify-dirs branch. I guess you could also just wrap calls to pki --verify with a script and add --cacert/crl arguments as appropriate (then you'd have more control if the CA certs and CRLs are e.g. stored in the same directory with different file extensions). Regards, Tobias
Re: [strongSwan] pki --verify Command
Hi Andreas, Thank you for the clarification. I agree as a user you wouldn't need this very often, but it comes in handy in some cases. If I were to implement this, do you thing the existing behavior should stay the same, unless you specify an additional argument? So here are the options: 1- "pki --verify --in certfile" stays the same if no additional arguments are supplied 2- "pki --verify --in certfile " change it to use the "default" trust store if no additional arguments are supplied Independent of the first choice above, we can add new commands line options to point to the paths of where CA/crls are stored: 3-"pki --verify --in certfile --capath path-to-ca's --crlpath path-to-crls 4-Or we can change existing options --cacert and --crl such the if the supplied argument is a directory we treat them as such and load whatever CA's CRLs needed for verification. Personally I like 2 and 4 together. Thanks for any input in advance. Regards, Jafar On 2/10/2018 2:09 AM, Andreas Steffen wrote: Hi Jafar, "pki --verify" is a command that is not intended to be used very often. There are some rare cases where you might be in doubt whether a certificate trust chain is correct and therefore might want to check it out by usually increasing the debug level to 3. Thus no effort has been taken to automate the verification process for multi-level trust chains. You are free to propose and implement some extensions to the "pki --verify" command. Regards Andreas On 09.02.2018 22:10, Jafar Al-Gharaibeh wrote: Hi, When invoking the "pki --verify" command, the user has to supply all of the CA certs along the trust chain for the verification to take place appropriately. This could be cumbersome if the trust chain is long (>1). If there are CRLs, they also have to be supplied as well. If the certificate store is known (default location for example such as /etc/ipsec.d/), shouldn't this all be done automatically? i.e, once you know the certificate to be verified, you can lookup the issuers all the way up to the root CA with their associated CRLs. Is there any reason why it doesn't work that way, other than nobody gotten around to doing it? Regards, Jafar == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Networked Solutions HSR University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[INS-HSR]==
Re: [strongSwan] pki --verify Command
Hi Jafar, "pki --verify" is a command that is not intended to be used very often. There are some rare cases where you might be in doubt whether a certificate trust chain is correct and therefore might want to check it out by usually increasing the debug level to 3. Thus no effort has been taken to automate the verification process for multi-level trust chains. You are free to propose and implement some extensions to the "pki --verify" command. Regards Andreas On 09.02.2018 22:10, Jafar Al-Gharaibeh wrote: > Hi, > > When invoking the "pki --verify" command, the user has to supply all > of the CA certs along the trust chain for the verification to take place > appropriately. This could be cumbersome if the trust chain is long > (>1). If there are CRLs, they also have to be supplied as well. If the > certificate store is known (default location for example such as > /etc/ipsec.d/), shouldn't this all be done automatically? i.e, once you > know the certificate to be verified, you can lookup the issuers all the > way up to the root CA with their associated CRLs. Is there any reason > why it doesn't work that way, other than nobody gotten around to doing it? > > Regards, > Jafar == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Networked Solutions HSR University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[INS-HSR]== smime.p7s Description: S/MIME Cryptographic Signature
[strongSwan] pki --verify Command
Hi, When invoking the "pki --verify" command, the user has to supply all of the CA certs along the trust chain for the verification to take place appropriately. This could be cumbersome if the trust chain is long (>1). If there are CRLs, they also have to be supplied as well. If the certificate store is known (default location for example such as /etc/ipsec.d/), shouldn't this all be done automatically? i.e, once you know the certificate to be verified, you can lookup the issuers all the way up to the root CA with their associated CRLs. Is there any reason why it doesn't work that way, other than nobody gotten around to doing it? Regards, Jafar
