I need to create a PEM file of a SSL (CA) certificate. Chrome does provide an option to view the certficate and export it as Base64 encoded X.509 (.CER)* file. In addition, the file extension can be changed to .PEM. Does the certificate only contain public information and can it safely be shared with other people (let's say colleagues)?
E.g. Stackoverflow contains a Root CA certificate. If I create the PEM file and share it with somebody, does it even matter or is there any security risk?
Background info: I need to export the SSL certificate (as .PEM) from an API endpoint in order to add it as trusted CA certificate in Postman.
Related
I am trying to set an HTTP load balancer with SSL.
I have two files - certificate.pem and unencryptedkey.pem.
But the UI of google asks for three fields:
Public key certificate,
Certificate chain,
Private key
What goes where and where do I get the third one?
I managed to use only 2 but the browser asks for permission and that is wrong.
When you buy the SSL certificate you should get some more files. In my case, I got a .ca file (certificate chain), a .crt file (the certificate), a .csr file (the request), and a .key file (your private key)
You need
public key => the crt file
certificate chain => your ca file(s concatenated)
private key => your .key
My guess is that you have created the certificates, i.e. you haven't purchased them from some certificate authority. With self-signed certificates browser warns you, since certificate validity can't be verified from a certificate authority.
If this is the case, you should do some learning regarding certificates and how they work.
I have a backend server with SSL only as defaut public interface. This server listens on 443 with cert, key and ca files on, ssl verify client is set to true.
On client side, I have client cert, key and a ca file made of 2 CA files catted together (intermediate CA, root CA) in a single ca.pem file. When I do curl request on my backend server, it works fine. I also tested the server / client cert and key with gnutls-serv and openssl s_server to ensure all was valid.
But when I create a keystore on Apigee (client cert and key file [pem format]) and a trustore (ca.pem file), there is an error:
- target.name fsbca-test
- Properties
- Expression ("fsbca-test" equals target.name)
- ExpressionResult true
- Tree TARGET_fsbca-test
- error The Service is temporarily unavailable
- error.cause General SSLEngine problem
- error.cause.cause General SSLEngine problem
- error.class com.apigee.messaging.adaptors.http.HttpAdaptorException
- state TARGET_REQ_FLOW
- type ErrorPoint
If I put SSL verify client to false on my backend, then the request is correctly diverted by Apigee and I get the response.
If I put IgnoreValidationErrors to true in the target endpoints property, then the request is diverted to my backend server but I can see an error in the server's log: "client sent no required SSL certificate while reading c...".
Any ideas about what could be wrong in what I am doing?
Additional track: could it be an issue on Apigee side with the CA file made of 2 certs (it may ignore trailing certificates found in a .pem). If wanted to test pkcs12 and jks but I failed to upload them to Apigee (the API doc page only describes .pem, JAR and cert action). I wrote a small Java client with pkcs12 keystore and jks trustore and it worked fine from my local workstation.
Thank you in advance for any piece of information that could help me.
Regards
Fr
You should upload your certificates separately (one per cert), and you need the entire trust chain of certificates to be stored in your truststore.
Here is the page about SSL to your backend.
EDIT:
Here is a method I know works:
1) Separate certs into separate PEM files. Do not put more than once cert in a file.
2) Validate each cert using openssl:
openssl x509 -noout -text -in <cert file name>
Validate that no certs are expired, and that the Subject and Issuer fields create a chain of all the certs, with identical names.
The server's certificate, the root certificate, and all certificates in between need to be in the truststore.
Bit of a silly question, but:
What kind of file(s) do you get when you buy an SSL certificate from a trusted CA?
Is there a .pfx file?
I'm working on a small tool to manage SSL certificates, but I'm not sure exactly what kind of certificates I'll be dealing with besides the self-signed ones that I create myself.
Thanks!
.pfx file extension is one. The below text from IBM has some indepth information.
Certificate file types
Certificates and keys are stored in several types of files.
Files that store certificates and keys can have the following formats:
.pem
A privacy-enhanced mail file, which has a file extension of .pem, begins and ends with the following lines:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
A privacy-enhanced mail format supports multiple digital certificates, including a certificate chain. If your organization uses certificate chaining, use this format to create CA certificates.
.arm
A file with an extension of .arm contains a base-64 encoded ASCII representation of a certificate, including its public key, but not its private key. An .arm format is generated and used by the IBM® Key Management utility. Specify this format to extract a self-signed certificate from the machine on which the self-signed certificate was generated to the machine that will use the self-signed certificate as the CA certificate.
.der
A file with an extension of .der contains binary data. This format can be used only for a single certificate, unlike a file with a privacy-enhanced mail format, which can contain multiple certificates. Specify this format to extract a self-signed certificate from the machine on which the self-signed certificate was generated to the machine that will use the self-signed certificate as the CA certificate.
.pfx (PKCS12)
A PKCS12 file, which has an extension of .pfx, contains a certificate (CA-issued certificate or self-signed certificate) and a corresponding private key. Use this format to transfer the contents of a keystore to a separate machine. For example, you can create and install a certificate and private key using key management utility, export the certificate and key to a PKCS12 file, then import the file into another keystore. This format is also useful for converting from one type of SSL implementation to a different implementation. For example, you can create and export a PKCS12 file using the IBM Key Management utility, then import the file on another machine using the OpenSSL CertTool utility.
The text above is a verbatim copy from IBM Eclipse Help.
I am trying to create an https endpoint for my azure service. I was given an p7b file that I converted into a cer file. From the cer I was able to convert with a few lines of c# to a pfx.
var cert = new X509Certificate2(#"certpath", "
var bytes = cert.Export(X509ContentType.Pfx, "password");
File.WriteAllBytes(#"certpath\cert.pfx", bytes);
Now when I upload the cert to azure everything seems ok, I copy the thumbprint and try to upgrade with the new thumbprint as part of the end point and I get an error in azure.
Certificate with thumbprint 3FA490D1D4957942CD2ED545F6E823D0008796EA2 associated with HTTPS input endpoint "endpointName" does not contain private key.
How did you convert the .p7b to a .cer? You're problem is that cer files don't contain the private key information, so when you exported it as a pfx, it doesn't have the information that it needs to work with SSL.
The easiest way to convert to a pfx is probably to import the certificate onto your local machine (using certmgr.msc), then export it making sure you select the "Yes, export the private key" option.
EDIT: After doing some more research after GregS' comment, the problem is still the same, you're pfx doesn't have the private key it needs to work with SSL, but the cause is actually that the .p7b file doesn't have a private key to begin with. You need to use a different certificate. There is already a question related to this on server fault.
I had the same problem trying to generate .pfx for Azure. The p7b certificate was generated by Thawte. After some research I was able to make it work.
Generate CSR (certificate request) from IIS. It could be your local IIS.
https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO9171
Generate the certificate based on the CSR. The CA takes care of this. If you are generating a self-signed certificate you also could do that from ISS. This is important because when you import it (step 3) IIS will verify that the certificate was generated there.
Import the certificate to your local IIS. It must be a .cer file. Just open your p7b file and you will see the certificate chain in there. Export your domain certificate to a .cer file. Then you can use it to import it to IIS.
https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO10664
Export the certificate to .pfx from IIS. At this point the certificate contains an appropriate private key added by IIS. When you export it, IIS will ask you for a password.
https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO10034
I had exactly the same problem as you once and here is the story of that:
Windows Azure, SSL, Self-Signed Certificate and Annoying HTTPS Input Endpoint Does Not Contain Private Key Error
Getting pfx file from SSL certificate from godaddy. Details here in case it helps.
While I know nothing about SSL or installing SSL Certificates, I'm sure one of the many results Google will give me for CentOS, SSL certs and Apache would help.
However, the certificate files which have been provided for this project are a .pfx file, .cer (the certificate) file and a .txt (apparently a certificate request) file, none of which are mentioned in the articles I'm finding.. they all talk of .crt and .key files.
Is there a particular way I should be converting these files, presumably via openssl, into something I can use in Apache?
.pfx files tend to be PKCS#12 files (which will contain the private key, the certificate and possibly the issuer certificate chain). They're sometimes called .p12. OpenSSL can extract private key and certificate from PKCS#12 files (via its openssl pkcs12 command), you should be able to find documentation to do this, via Google or other questions on SO.