On 20.09.23 10:01, openssl-users-request@xxxxxxxxxxx digested:
Date: Wed, 20 Sep 2023 07:28:46 +0000 From: "Doody, Stephen" <s.doody@xxxxxxx> We have a pem file that a colleague believes contains a private and a public key.
If it is PEM, it should have cleartext headers above every encoded block *telling* you what data it contains, like so:
# grep BEGIN [PT]*.pem *.crt *.key PROD-CA.pem:-----BEGIN CERTIFICATE----- PROD-CA.pem:-----BEGIN X509 CRL----- PROD-CA.pem:-----BEGIN CERTIFICATE----- PROD-CA.pem:-----BEGIN X509 CRL----- PROD-CA.pem:-----BEGIN CERTIFICATE----- PROD-CA.pem:-----BEGIN X509 CRL----- PROD-CA.pem:-----BEGIN CERTIFICATE----- PROD-CA.pem:-----BEGIN X509 CRL----- PROD-CA.pem:-----BEGIN CERTIFICATE----- PROD-CA.pem:-----BEGIN X509 CRL----- PROD-CA.pem:-----BEGIN CERTIFICATE----- PROD-CA.pem:-----BEGIN X509 CRL----- PROD-CA.pem:-----BEGIN CERTIFICATE----- PROD-CA.pem:-----BEGIN X509 CRL----- PROD-CA.pem:-----BEGIN CERTIFICATE----- PROD-CA.pem:-----BEGIN X509 CRL----- TCP2443-dh2048.pem:-----BEGIN DH PARAMETERS----- TCP443-dh2048.pem:-----BEGIN DH PARAMETERS----- demux.crt:-----BEGIN CERTIFICATE----- demux.key:-----BEGIN RSA PRIVATE KEY-----
The pubkey.pem file that is created only contains the public key and nothing else, so the 3rd party service can no longer connect to our system as it doesn't recognise this as a valid certificate and complained that it was not trusted.
[...]
The 3rd party service can now connect to our system but viewing the details of the pubkey2.pem file it looks identical to the original ourcert.pem file.
If the 3rd party *really* needs a *certificate* to trust (an assertion that that last paragraph casts considerable doubt on ...), then they'll need to tell you which *CAs* they're willing to trust, and one of those will need to create a new certificate for the keypair if your saved data doesn't contain one. (Of course, their answer may be "set one up yourself and we'll tell our software to trust *that* CA, too".) They also should make mention of certain additional requirements (do they connect to an IP, or a hostname? Does the cert need to confirm that data? In the CN, the SANs, or both? etc.).
Without looking at the actual data, I'd agree that the pubkey2.pem file likely contains *only* the public key, so your last paragraph suggests that they *can* trust a *pubkey* instead ... in which case, mission accomplished ... ?
Kind regards, -- Jochen Bern Systemingenieur Binect GmbH
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
