[strongSwan] pki --verify Command

[Jafar Al-Gharaibeh]

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
>