Closed tall27 closed 5 months ago
@tall27 I think the use-case has merit, but have concerns about moving the vCert CLI in a direction that it starts interacting with "other" systems over the network. Scanafi pretty much accomplishes the same things, in a slightly different way maybe, and is built for the purpose of discovering certificates. It automatically handles importing (if it doesn't exist already), and in the case of TLSPC, updates the last-seen attribute on import.
@BeardedPrincess Can we close this issue?
BUSINESS PROBLEM I'd like to use vcert to validate the certificate install on the remote machine? Although same it possible with API calls, we'd like to standardize on a single tool that can do it all.
PROPOSED SOLUTION
vcert --testcert -import FQDN [ -IP , -Port]
When run, vcert would retrieve a certificate from the target box, then will try to find a cert with CN in TLS Protect, compare their SerialNumbers and reply OK\Fail result. if IP is used - retrieve the cert from selected IP:443, and use CN for the processing. Port can go with FQDN and IP flags and replace the default one.
The -import flag will make vcert to import certificate it found to TLS Protect along with the IP\FQDN as a device and Port. Same as what we have in TPP vedadmin (quick discovery).
CURRENT ALTERNATIVES
WEDSK API calls allow to reach same functionality, but require coding knowledge and sometimes application environments or runtimes.
VENAFI EXPERIENCE
Good experience with TLS Protect