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


Reply via email to