Start with the objects you actually have
A certificate binds an issuer-signed identity to a public key. A CSR contains a requested identity and public key signed by the requesting private key; it is not a certificate issued by a CA. A private key is the sensitive counterpart used to prove control. File extensions alone cannot establish which object a file contains.
Choose Inspect first and add the certificate or CSR. Read the subject, requested SANs, public-key fingerprint and CSR signature result. A valid CSR signature shows that its signed request is intact and was made using the corresponding key; it does not establish that a CA approved any requested name.
Use the optional key check only when necessary
If you need to confirm a key match, enable local private-key processing and select the key or supported encrypted PFX. The workbench signs a fresh random challenge and verifies it using the public keys in the supplied objects. A positive match proves this key pair relationship, not the trustworthiness of the certificate issuer.
When several certificates use the same public key, more than one match is possible. Select the intended certificate number and inspect its serial, validity and SAN list. A renewed certificate can reuse a key while changing its names, dates or issuer chain.
Keep the result appropriate for its audience
The metadata report omits passwords, private-key bytes and CSR challenge-password values. It can still contain internal DNS names, organization names and certificate identifiers. Review those fields before attaching a report to a ticket or publishing it.
The public ZIP contains original signed CSR bytes when requested. That preserves any challengePassword attribute, even though the summary hides its value. Share original requests only with the intended recipient. Private outputs require a separate encrypted-key or PFX operation and should be handled as secrets.