Needed to renew a certificate on a PI Vision / PI Web API Server, so looked into https://customers.osisoft.com/s/knowledgearticle?knowledgeArticleUrl=KB01649 for details as the certificate did not show up in the dialog to select a new one.
Not the verbose logging indicates: <...id...> not shown: certificate failed basic validation policy
Not what does that mean? I have a valid chain of trust, certificate is not expired, and certificate details show no difference with the previous one. Any details available why the certificate is not shown?
Now reverting to exchanging the certificate in IIS... although that is not the recommended path. The PI Web API Admin utility does show the Cert set in IIS, and it allows to save this configuration. So that is a workaround which does not leave the PI Web API configuration stale.
Hey Roger,
If I had to guess, I would say that your certificate revocation chain could not be verified.
The PI Web API admin utility performs a "hard fail" which means that if the entire revocation chain cannot be contacted to confirm that the certificate hash is not listed in the revocation server's certificate revocation list, then it will not allow it to be trusted.
Browsers, IIS, most other software, etc, perform "soft fails" which means that if the entire revocation chain cannot be contacted, then it will simply assume it hasn't been revoked and it will let you use it.
The Web API developers did not feel comfortable populating a non-verifiable certificate in our admin utility because users may not be aware that their CRL server is offline or otherwise unreachable, but we put in a concession that if the certificate is bound already to that port, then we will allow it to continue to be used.
This prevents people from unknowingly using a certificate that was never actually verified, while also not preventing users from using the certificate anyway if they so choose. The procedure you followed is exactly the procedure we recommend when the CRL server is not reachable.
To verify if this is in fact the case, can you run the certutil -verify <pathtocertificate>. That output should show why it failed.
Kelsey