I am generating two CSRs ( Certificate signing request )
1 . using java keytool i get a .csr format file.
using IBM key management tool i get .arm file.
Though both the files contains the same kind of data ( ie . base64 encoded public key details)
My question "can i rename .csr file to .arm" will it be the same ...
Thanks.
The most common syntax for a CSR is PKCS#10, which can be represented in binary or text formats. A CSR contains a number of pieces of information including: a public key, the subject distinguished name, a signature, and optional attributes. If you can view the files in a text editor and they look similar to this:
-----BEGIN CERTIFICATE REQUEST-----
MIIBnTCCAQYCAQAwXTELMAkGA1UEBhMCU0cxETAPBgNVBAoTCE0yQ3J5cHRvMRIw
EAYDVQQDEwlsb2NhbGhvc3QxJzAlBgkqhkiG9w0BCQEWGGFkbWluQHNlcnZlci5l
eGFtcGxlLmRvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr1nYY1Qrll1r
uB/FqlCRrr5nvupdIN+3wF7q915tvEQoc74bnu6b8IbbGRMhzdzmvQ4SzFfVEAuM
MuTHeybPq5th7YDrTNizKKxOBnqE2KYuX9X22A1Kh49soJJFg6kPb9MUgiZBiMlv
tb7K3CHfgw5WagWnLl8Lb+ccvKZZl+8CAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GB
AHpoRp5YS55CZpy+wdigQEwjL/wSluvo+WjtpvP0YoBMJu4VMKeZi405R7o8oEwi
PdlrrliKNknFmHKIaCKTLRcU59ScA6ADEIWUzqmUzP5Cs6jrSRo3NKfg1bd09D1K
9rsQkRc9Urv9mRBIsredGnYECNeRaK5R1yzpOowninXC
-----END CERTIFICATE REQUEST-----
then they are text (aka PEM) encoded CSRs. These text encoded CSRs can be decoded and viewed using the following openssl command:
openssl req -in your-csr-filename -noout -text
Renaming the file will not affect openssl's ability to decode them. However, some applications that process CSRs may expect a particular filename extension.
You can inspect your certificate signing request (csr) using OpenSSL with a command such as:
openssl x509 -req -in yourfile.csr -text -noout
I'm assuming that IBM's thingy is a wrapper around openssl so I would expect your .arm to be an x509 certificate going by a different name. Be interested to hear what you get back ...
The answer is yes. The .arm file is the same format as .csr. As you stated, they both contain the same type of data and therefore can simply be renamed. Furthermore, the common types of CSR requests are PKCS#10 and PKCS#12.
#snow60y: You won't see anything with 'openssl x509 -req -in yourfile.csr -text -noout' because there is no private key contained within the CSR and it is not signed, so it is not an x509 yet. A CSR should NEVER contain a private key and therefore, analyzing with that command should fail. You can use that command with a SIGNED cert, but not the request. For the request, use:
openssl req -in your-csr-filename -noout -text
Related
I'm having problems understanding the difference between files produced by openssl and how to detect them.
For example I'm trying to generate Self-signed cert with private key and generate JKS file from p12
format. I'm googling like a madman but I still don't know how to generate it correctly to be able to use following commands.
openssl pkcs12 -export -in user.pem -inkey user.key -certfile user.pem -out testkeystore.p12
keytool -importkeystore -srckeystore testkeystore.p12 -srcstoretype pkcs12 -destkeystore wso2carbon.jks -deststoretype JKS
Source: https://www.ibm.com/support/pages/how-generate-jks-keystore-existing-private-key
I found a couple of different commands to generate Self-signed cert and private key but I don't know how to map resulting files to the commands above and whats worse I don't understand what those commands do.
I mean I see what files they generate and understand that certificate and private key used to sign it ( or maybe the other way around :| ) but what is the difference between those commands and is cert.pem === certificate.crt - Those file extensions are driving me crazy.
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem
This is yet another situation where I'm having similar issues with the openssl command. At this point I'm even ready to read some RFC ( I hope it won't come to this :) )
Thanks in advance for help
Those file names represent different parts of the key generation and verification process. Please note that the names are just convention, you could just as easily call the files pepperoni.pizza and the content will be the same, so do be conscious of how you use the filenames.
A brief primer on PKI - Keys come in two halves, a public key and a private key. The public key can be distributed publicly and widely, and you can use it to verify, but not replicate, information generated using the private key. The private key must be kept secret.
.key files are generally the private key, used by the server to encrypt and package data for verification by clients.
.pem files are generally the public key, used by the client to verify and decrypt data sent by servers. PEM files could also be encoded private keys, so check the content if you're not sure.
.p12 files have both halves of the key embedded, so that administrators can easily manage halves of keys.
.cert or .crt files are the signed certificates -- basically the "magic" that allows certain sites to be marked as trustworthy by a third party.
.csr is a certificate signing request, a challenge used by a trusted third party to verify the ownership of a keypair without having direct access to the private key (this is what allows end users, who have no direct knowledge of your website, confident that the certificate is valid). In the self-signed scenario you will use the certificate signing request with your own private key to verify your private key (thus self-signed). Depending on your specific application, this might not be needed. (needed for web servers or RPC servers, but not much else).
A JKS keystore is a native file format for Java to store and manage some or all of the components above, and keep a database of related capabilities that are allowed or rejected for each key.
The commands you list look fine to me, and I don't see a question beyond asking what the different files are for. If you need more information, please enrich your question.
.key is the private key. This is accessible the key owner and no one else.
.csr is the certificate request. This is a request for a certificate authority to sign the key. (The key itself is not included.)
.crt is the certificate produced by the certificate authority that verifies the authenticity of the key. (The key itself is not included.) This is given to other parties, e.g. HTTPS client.
.pem is a text-based container using base-64 encoding. It could be any of the above files.
-----BEGIN EXAMPLE-----
...
-----END EXAMPLE-----
.p12 is a PKCS12 file, which is a container format usually used to combine the private key and certificate.
There isn't only one extension. For example you may see certificates with either the .crt or a .pem extension.
Just to add more info: .der, another (binary) encoding (either public or private key, or csr)
I need to upload a qualified certificate in .pfx file, I have .req and .pfx with private key files from requesting the certificate, and I got the qualified .crt certificate from the company that do these. How can I join the password and the certificate with qualified roots?
I already tried openssl Openssl pkcs12 -export -inkey KEYFILENAME -in CERTFILEFILENAME -out final.pfx
output was: error in pkcs12, expecting: any private key
Thank you, this is very important for me.
You say you have '.pfx with private key' but do not say anything about a PEM-format private key. The input for pkcs12 -export -inkey must be a PEM-format private key.
Extract the privatekey from the existing/original pfx with openssl pkcs12 -in oldpfx -nocerts without -export and either store it in a file and feed that to -inkey, or just concatenate with your cert and pipe the combination to openssl pkcs12 -export without -in -inkey.
Note this 'joins' the privatekey and the certificate, but there is no permanent linkage to any password(s); each privatekey file (PEM format or pfx/p12) can be encrypted with any password you choose (except openssl will usually reject very short passwords) and they don't need to be the same, and each can be changed without changing the privatekey (and cert) -- although you may well choose to make them and keep them the same for your own convenience.
Also note that certificates issued by public CAs like Verisign and GoDaddy etc usually depend on intermediate aka chain certificates, and in many perhaps most cases software that uses a pfx/pf12 needs it to contain those intermediate/chain certs. However, you didn't give any clues about this in your Q and there are so many possible variations of how to select, get, convert and use chain certs I couldn't fit them all in one SO answer.
For school we are currently studying SSL certificates.
For this week's assignment we had to install Fedora Workstation on VirtualBox and do some SSL-stuff.
One of the assignments was the following:
generate a public/private keypair and a CSR with the openssl command.
I generated a public/private keypair using the following command:
openssl genrsa -out Desktop/mykey.key 2048
After I generated the keypair I had to verify it. But how do you verify a key? What is really meant by that? Just get out the public key and check if it matches the private key? This is the first question.
I generated the CSR using the following command:
openssl req -new -key Desktop/mykey.key -out Desktop/myCSR.csr
This is the right way, right?
Checking/verifying the CSR file was done using this command:
openssl req -text -noout -verify -in Desktop/myCSR.csr
I think that's the right way too.
This was the "easy" part, now comes the harder part:
We had to use xca to create a database and a CA Root Certificate. Then we had to import the csr from above question and sign it. I signed it by right clicking on it and choosing sign. Then we had to export both the CA and the signed key and verify it. But what do they mean exactly? My guess is to verify that the certificate is signed by the CA, but I'm having problems with that.
We have to use openssl x509 for that, but it just isn't working.
When I right click the signed key and export it as a PEM file, in that file is the following:
----- BEGIN CERTIFICATE REQUEST -----
MIIC6......
----- BEGIN CERTIFICATE REQUEST -----
while the assigment says: export the signed certificate. But is this even a certificate?
And how do I verify it?
I used many commands, like
openssl x509 -in Desktop/exported.pem -text -noout
But the output I get is always something like this:
I have tried all sorts of commands and read all google pages, but nothing helps.
this is the second question
Hope you all can help, Thanks!
When you verify a certificate, you are checking whether it's CA is recognised, and it matches the CA's fingerprint. It doesn't look like you are providing the CA cert to the openssl command. Try specifying -CA <your CA cert file:
$ openssl x509 --help
...
-CA arg - set the CA certificate, must be PEM format.
How can I create a PEM file from an SSL certificate?
These are the files that I have available:
.crt
server.csr
server.key
Your keys may already be in PEM format, but just named with .crt or .key.
If the file's content begins with -----BEGIN and you can read it in a text editor:
The file uses base64, which is readable in ASCII, not binary format. The certificate is already in PEM format. Just change the extension to .pem.
If the file is in binary:
For the server.crt, you would use
openssl x509 -inform DER -outform PEM -in server.crt -out server.crt.pem
For server.key, use openssl rsa in place of openssl x509.
The server.key is likely your private key, and the .crt file is the returned, signed, x509 certificate.
If this is for a Web server and you cannot specify loading a separate private and public key:
You may need to concatenate the two files. For this use:
cat server.crt server.key > server.includesprivatekey.pem
I would recommend naming files with "includesprivatekey" to help you manage the permissions you keep with this file.
I needed to do this for an AWS ELB. After getting beaten up by the dialog many times, finally this is what worked for me:
openssl rsa -in server.key -text > private.pem
openssl x509 -inform PEM -in server.crt > public.pem
Thanks NCZ
Edit: As #floatingrock says
With AWS, don't forget to prepend the filename with file://. So it'll look like:
aws iam upload-server-certificate --server-certificate-name blah --certificate-body file://path/to/server.crt --private-key file://path/to/private.key --path /cloudfront/static/
http://docs.aws.amazon.com/cli/latest/reference/iam/upload-server-certificate.html
A pem file contains the certificate and the private key. It depends on the format your certificate/key are in, but probably it's as simple as this:
cat server.crt server.key > server.pem
Additionally, if you don't want it to ask for a passphrase, then need to run the following command:
openssl rsa -in server.key -out server.key
this is the best option to create .pem file
openssl pkcs12 -in MyPushApp.p12 -out MyPushApp.pem -nodes -clcerts
I was trying to go from godaddy to app engine. What did the trick was using this line:
openssl req -new -newkey rsa:2048 -nodes -keyout name.unencrypted.priv.key -out name.csr
Exactly as is, but replacing name with my domain name (not that it really even mattered)
And I answered all the questions pertaining to common name / organization as www.name.com
Then I opened the csr, copied it, pasted it in go daddy, then downloaded it, unzipped it, navigated to the unzipped folder with the terminal and entered:
cat otherfilegodaddygivesyou.crt gd_bundle-g2-g1.crt > name.crt
Then I used these instructions from Trouble with Google Apps Custom Domain SSL, which were:
openssl rsa -in privateKey.key -text > private.pem
openssl x509 -inform PEM -in www_mydomain_com.crt > public.pem
exactly as is, except instead of privateKey.key I used name.unencrypted.priv.key, and instead of www_mydomain_com.crt, I used name.crt
Then I uploaded the public.pem to the admin console for the "PEM encoded X.509 certificate", and uploaded the private.pem for the "Unencrypted PEM encoded RSA private key"..
.. And that finally worked.
All of the files (*.crt, server.csr, server.key) may already be in PEM format, what to do next with these files depends on how you want to use them, or what tool is using them and in which format it requires.
I'll go a bit further here to explain what are the different formats used to store cryptography materials and how to recognise them as well as convert one to/from another.
Standards
Standards
Content format
File encoding
Possible content
X509
X
Certificates
PKCS#1
X
RSA keys (public/private)
PKCS#7
X
Certificates, CRLs
PKCS#8
X
Private keys, encrypted private keys
PKCS#12
X
Certificates, CRLs, private keys
JKS
X
Certificates, private keys
PEM
X
DER
X
Common combinations
Content \ Encoding
PEM (*)
DER (**)
Binary
X509
X
X
PKCS#1
X
X
PKCS#7 (***)
X
X
PKCS#8
X
X
PKCS#12 (***)
X
JKS (***)
X
This is a gist explains the same thing + commands for conversion/verification/inspection.
In conclusion, typical steps to work with cryptography/PKI materials:
Understand which format they are in (use verification/inspection commands)
Understand which format they are required (read doc)
Use conversion commands to convert the files
Optional: use verification/inspection commands to verify converted files
What I have observed is: if you use openssl to generate certificates, it captures both the text part and the base64 certificate part in the crt file. The strict pem format says (wiki definition) that the file should start and end with BEGIN and END.
.pem – (Privacy Enhanced Mail) Base64 encoded DER certificate,
enclosed between "-----BEGIN CERTIFICATE-----" and "-----END
CERTIFICATE-----"
So for some libraries (I encountered this in java) that expect strict pem format, the generated crt would fail the validation as an 'invalid pem format'.
Even if you copy or grep the lines with BEGIN/END CERTIFICATE, and paste it in a cert.pem file, it should work.
Here is what I do, not very clean, but works for me, basically it filters the text starting from BEGIN line:
grep -A 1000 BEGIN cert.crt > cert.pem
Trying to upload a GoDaddy certificate to AWS I failed several times, but in the end it was pretty simple. No need to convert anything to .pem. You just have to be sure to include the GoDaddy bundle certificate in the chain parameter, e.g.
aws iam upload-server-certificate
--server-certificate-name mycert
--certificate-body file://try2/40271b1b25236fd1.crt
--private-key file://server.key
--path /cloudfront/production/
--certificate-chain file://try2/gdig2_bundle.crt
And to delete your previous failed upload you can do
aws iam delete-server-certificate --server-certificate-name mypreviouscert
Download certificate from provisional portal by appleId,
Export certificate from Key chain and give name (Certificates.p12),
Open terminal and goto folder where you save above Certificates.p12 file,
Run below commands:
a) openssl pkcs12 -in Certificates.p12 -out CertificateName.pem -nodes,
b) openssl pkcs12 -in Certificates.p12 -out pushcert.pem -nodes -clcerts
Your .pem file ready "pushcert.pem".
Open terminal.
Go to the folder where your certificate is located.
Execute below command by replacing name with your certificate.
openssl pkcs12 -in YOUR_CERTIFICATE.p12 -out YOUR_CERTIFICATE.pem -nodes -clcerts
Hope it will work!!
On Windows, you can use the certutil tool:
certutil -encode server.crt cert.pem
certutil -encode server.key key.pem
You can combine both files to one in PowerShell like this:
Get-Content cert.pem, key.pem | Set-Content cert-and-key.pem
And in CMD like this:
copy cert.pem+key.pem cert-and-key.pem /b
I need to setup an Apache 2 server with SSL.
I have my *.key file, but all the documentation I've found online, *.crt files are specified, and my CA only provided me with a *.cer file.
Are *.cer files the same as *.crt? If not, how can I convert CER to CRT format?
File extensions for cryptographic certificates aren't really as standardized as you'd expect. Windows by default treats double-clicking a .crt file as a request to import the certificate into the Windows Root Certificate store, but treats a .cer file as a request just to view the certificate. So, they're different in the sense that Windows has some inherent different meaning for what happens when you double click each type of file.
But the way that Windows handles them when you double-click them is about the only difference between the two. Both extensions just represent that it contains a public certificate. You can rename a certificate file to use one extension in place of the other in any system or configuration file that I've seen. And on non-Windows platforms (and even on Windows), people aren't particularly careful about which extension they use, and treat them both interchangeably, as there's no difference between them as long as the contents of the file are correct.
Making things more confusing is that there are two standard ways of storing certificate data in a file: One is a "binary" X.509 encoding, and the other is a "text" base64 encoding that usually starts with "-----BEGIN CERTIFICATE-----". These encode the same data but in different ways. Most systems accept both formats, but, if you need to, you can convert one to the other via openssl or other tools. The encoding within a certificate file is really independent of which extension somebody gave the file.
Basically there are two CER certificate encoding types, DER and Base64. When type DER returns an error loading certificate (asn1 encoding routines), try the PEM and it shall work.
openssl x509 -inform DER -in certificate.cer -out certificate.crt
openssl x509 -inform PEM -in certificate.cer -out certificate.crt
According to documentation mod_ssl:
SSLCertificateFile:
Name: SSLCertificateFile
Description: Server PEM-encoded X.509 certificate file
Certificate file should be PEM-encoded X.509 Certificate file:
openssl x509 -inform DER -in certificate.cer -out certificate.pem
CER is an X.509 certificate in binary form, DER encoded.
CRT is a binary X.509 certificate, encapsulated in text (base-64) encoding.
It is not the same encoding.
I use command:
openssl x509 -inform PEM -in certificate.cer -out certificate.crt
But CER is an X.509 certificate in binary form, DER encoded.
CRT is a binary X.509 certificate, encapsulated in text (base-64) encoding.
Because of that, you maybe should use:
openssl x509 -inform DER -in certificate.cer -out certificate.crt
And then to import your certificate:
Copy your CA to dir:
/usr/local/share/ca-certificates/
Use command:
sudo cp foo.crt /usr/local/share/ca-certificates/foo.crt
Update the CA store:
sudo update-ca-certificates
I assume that you have a .cer file containing PKCS#7-encoded certificate data and you want to convert it to PEM-encoded certificate data (typically a .crt or .pem file). For instance, a .cer file containing PKCS#7-encoded data looks like this:
-----BEGIN PKCS7-----
MIIW4gYJKoZIhvcNAQcCoIIW0zCCFs8CAQExADALBgkqhkiG9w0BBwGggha1MIIH
...
POI9n9cd2cNgQ4xYDiKWL2KjLB+6rQXvqzJ4h6BUcxm1XAX5Uj5tLUUL9wqT6u0G
+bKhADEA
-----END PKCS7-----
PEM certificate data looks like this:
-----BEGIN CERTIFICATE-----
MIIHNjCCBh6gAwIBAgIQAlBxtqKazsxUSR9QdWWxaDANBgkqhkiG9w0BAQUFADBm
...
nv72c/OV4nlyrvBLPoaS5JFUJvFUG8RfAEY=
-----END CERTIFICATE-----
There is an OpenSSL command that will convert .cer files (with PKCS#7 data) to the PEM data you may be expecting to encounter (the BEGIN CERTIFICATE block in the example above). You can coerce PKCS#7 data into PEM format by this command on a file we'll call certfile.cer:
openssl pkcs7 -text -in certfile.cer -print_certs -outform PEM -out certfile.pem
Note that a .cer or .pem file might contain one or more certificates (possibly the entire certificate chain).
The answer to the question how to convert a .cer file into a .crt file (they are encoded differently!) is:
openssl pkcs7 -print_certs -in certificate.cer -out certificate.crt
If your cer file has binary format you must convert it by
openssl x509 -inform DER -in YOUR_CERTIFICATE.cer -out YOUR_CERTIFICATE.crt
The .cer and .crt file should be interchangable as far as importing them into a keystore.
Take a look at the contents of the .cer file. Erase anything before the -----BEGIN CERTIFICATE----- line and after the -----END CERTIFICATE----- line. You'll be left with the BEGIN/END lines with a bunch of Base64-encoded stuff between them.
-----BEGIN CERTIFICATE-----
MIIDQTCCAqqgAwIBAgIJALQea21f1bVjMA0GCSqGSIb3DQEBBQUAMIG1MQswCQYD
...
pfDACIDHTrwCk5OefMwArfEkSBo/
-----END CERTIFICATE-----
Then just import it into your keyfile using keytool.
keytool -import -alias myalias -keystore my.keystore -trustcacerts -file mycert.cer
Here is one case that worked for me if we need to convert .cer to .crt, though both of them are contextually same
Generate crt file:
openssl pkcs12 -in identity.p12 -nokeys -out mycertificate.crt
Generate key file:
openssl pkcs12 -in identity.p12 -out mycertificate.key -nodes -nocerts
where we should have a valid private key (identity.p12) PKCS 12 format, this one i generated from keystore (.jks file) provided by CA (Certification Authority) who created my certificate.
Just do
openssl x509 -req -days 365 -in server.cer -signkey server.key -out server.crt