[strongSwan] pki --verify Command

[Jafar Al-Gharaibeh]

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
>>
>
>