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