I have a CA like this in file file.pem:
-----BEGIN CERTIFICATE-----
MIIDczCCAlugAwIBAgIHALRRMXUkMTANBgkqhkiG9w0BAQ0FADBHMRswGQYDVQQD
DBJIdHRwQ2FuYXJ5IFJvb3QgQ0ExEzARBgNVBAoMCkh0dHBDYW5hcnkxEzARBgNV
BAsMCkh0dHBDYW5hcnkwHhcNMjAwMTE1MDc1MjUwWhcNMzEwMTEyMDc1MjUwWjBH
MRswGQYDVQQDDBJIdHRwQ2FuYXJ5IFJvb3QgQ0ExEzARBgNVBAoMCkh0dHBDYW5h
cnkxEzARBgNVBAsMCkh0dHBDYW5hcnkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDpDLS2xbpRfTgCPn9Xz0PdWNdppo7vUltGQlzJfD0FQZsyiCU3sYAe
oRGaInwgS4knBEt/9hxaLC8ivz9UlXWIhg8Xy4g+J463HfD4kP2fQElHfo+SlFwc
flkIVKgOB/rMgFMp6LH9YP+bmYMy3ndXYkTkYAGL6Q2EWO90HQLYkt2pm5ij7755
vp8Dksc7LHnHo0sqzrpB953Sx5dVTSyQ91fU3scxo8xvcJQG/vYfbEJA6rZunlLO
3NG8i8JhEYpEjWlf7MV0WIjlPk2vMCHKei/Wyd0msrmL12vjOl3IxMSZQn76SZ1k
+l9E+wuaAw61DnrzD2gkF3yfCNHr8xsrAgMBAAGjZDBiMB0GA1UdDgQWBBQpj7CB
UKauWN0/B4d2jAQxbmjTpDAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBtjAj
BgNVHSUEHDAaBggrBgEFBQcDAQYIKwYBBQUHAwIGBFUdJQAwDQYJKoZIhvcNAQEN
BQADggEBAKjH9gYYRg+BLXqey9FGd7mR5hCC3lB7NfLEyJULlAoLgzdGieXfcwdX
Qe5clq6Wfk35v2VxVBg1j/oxZYZyJxFvWiuJ840FHgOb5kD7qTS7i735PCbAyCVf
uSTonQw0Ny8gnjoTijjO/Dh0O6j2wr2kIHORdC2H4Kbya7jyriqY/M/tiuolDyBc
4RWW52pmDdFi+DMvdroRMaE/1fzDiYRB4ongMNLm7fytGTg9Dakhy7o4OC+dmlGm
miUEQIACm2cWrfI1/tjwh+BpbXG91i8y8FPA4YZ2iNmF1133dJhjNx66LETOfJA5
9dZqO1SpbFk4NVpI4UYzfzMdpqw2KgM=
-----END CERTIFICATE-----
And I want the hash of this with a SHA-256 hash value to have something like this:
"certificate_hash": "8eb1ec754c1d04af13efa97da1be05c90f1342e5"
But I don’t know how to do that. I know the hexadecimal value of my CA and tried to check with the final result of the convert, but it’s not the same. How can I have the SHA-256 hash value from this CA?
Signed SHA-256 hash value:
B2:62:DC:C4:F2:4A:AA:51:C9:5C:00:6C:0F:27:19:00:DE:42:3D:D3:8C:79:72:89:9A:8D:89:37:84:2E:1E:58
Signed SHA-1 hash value:
84:29:CA:F9:EE:3A:3C:CB:4A:08:42:66:0E:BA:2D:84:FC:B4:E5:51
You have a PEM encoded certificate. To compute the fingerprint, one first need to decode it from the PEM representation into a binary. For this, the header and footer (starting with -----) need to be removed and the rest need to be decoded as Base64. From the resulting binary the SHA-1 or SHA-256 hash values can then be computed.
In short, on the Linux command line (with shell prompt "$"):
$ grep -v ^- cert.pem | base64 -d | sha256sum
b262dcc4f24aaa51c95c006c0f271900de423dd38c7972899a8d8937842e1e58 -
$ grep -v ^- cert.pem | base64 -d | sha1sum
8429caf9ee3a3ccb4a0842660eba2d84fcb4e551 -
The b262dc... is exactly the same as the B2:62:DC:... from your question, only different.
Of course, one could also simply use openssl x509:
$ openssl x509 -in cert.pem -fingerprint -sha256
SHA256 Fingerprint=B2:62:DC:C4:F2:4A:AA:51:C9:5C:00:6C:0F:27:19:00:DE:42:3D:D3:8C:79:72:89:9A:8D:89:37:84:2E:1E:5
$ openssl x509 -in cert.pem -fingerprint -sha1
SHA1 Fingerprint=84:29:CA:F9:EE:3A:3C:CB:4A:08:42:66:0E:BA:2D:84:FC:B4:E5:51
Related
I've a certificate request (see bottom) of which I'd like get fingerprint preferably from command-line (Unix). If my goal was only to verify integrity of a PEM file on two machines I could just use e.g. sha256sum csr.pem value but I'd like to get the same fingerprint as Puppet does:
puppet:~# puppetserver ca list --all
Requested Certificates:
testbox (SHA256) 7C:8C:A2:2C:17:42:C1:B9:55:A0:1D:EE:0D:C1:B0:65:B0:B4:AF:83:68:77:A8:0D:C4:6C:B1:41:25:FF:E7:C2
This fingerprint value is printed on both testbox and puppet machines when bootstrapping testbox and only thing they both share is the CA certificate (private key of which is stored on puppet). So the algorithm shouldn't require any private keys on input.
I assume the algorithm is standard, but I don't know cryptographic formats and openssl enough to figure out how to get it, and I'd specifically like to use openssl or some other widely available command line utility (i.e. not Ruby).
One of my failed attempts:
testbox:~# openssl x509 -fingerprint -in /etc/puppetlabs/puppet/ssl/certificate_requests/testbox.pem
unable to load certificate
139644407518336:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
Here's the actual certificate request:
testbox:~# cat /etc/puppetlabs/puppet/ssl/certificate_requests/testbox.pem
-----BEGIN CERTIFICATE REQUEST-----
MIIEVzCCAj8CAQAwEjEQMA4GA1UEAwwHdGVzdGJveDCCAiIwDQYJKoZIhvcNAQEB
BQADggIPADCCAgoCggIBAKAT6FPs6RkT30lnNk0wpfhLtjrrAr/YdyDCUVTjV5jL
23iuLLSHes7yog/gACitGqCOnSz7J95OUtfGV+ACV8AEcyNpQazOqHhcLh15CYa7
8fDyVsoLzHWUKDMXhNllYrJFOoEDU/IP/y5hdS6e56pPZCVwYRxg9pjtvOX/FyUA
vXFA94IvqAgR2HdD7Vbr11mSmVNJuP9bWimhizvpzG4g3Xacvz7BhEZC5v/tIuH6
zaQtKCoBoxTFQhlFhY1F0iIMIjbTFTUuzPjCh5pMhXMxm0rgpH0SkvJp8bzesCGX
34JIDCOo6R197IttvbPh+6J91nMReOrYl4WAIMFHMz9L2dEClKbT0qWKjTHSUB6E
Pkia6d/gQzM4UcfP2NGAPnaWv3HZJPy6LnOHFoaxkfiMVGMlKISqF8cbkhGEneX0
V3Q8z60BAdr1q2i2rmPQkhp0MLwCoOzEcH13I43GhZuF/V6YbBcLt0UcEI0DC+VR
vP1sIFXj/BzQkITgzE9q067vRtgYVb85CtfESvSbLdci8noPz076wuaiRme8qzHM
SovvAcq6QGPKaB7K7veKAUW7riOaXHRzR6WAxE2t4WlZDmT/9liLPlxT38Mbl2LE
mVRPNvb1IUyWY5SoE4Dl/9ZNMlIReMrT/XVD/Udt5zOlKxica2wSHPIRyBDm5ah9
AgMBAAGgADANBgkqhkiG9w0BAQsFAAOCAgEAAkqLZQQGf8cHPqX+MWmMu42sHETv
CSqRvKM1oLcli4OCPF15axLNUAXg7+wSPOLfUkznkqukSs+ZZKoKex232ZesrDRn
IG1kkVrYRWAO6kgHHTnQJx0HOawny1OObfIlkbq/PSiprlPK5OfjyTgjK4oIDqIy
50Vifqv2akgW4/HirgUe54dILuXRlntFJtDXyanMHcRhg/Vy+I7hfIbimuBoIWuF
Z/ULNcj25+/m0VjAYNJ4gkV/TgIcWhmRLvq7AFeFo3tmEsmrbnXJnBnt1RCpAOY4
CF3T5etAsG+6JfQ/erY3Kh6sGK5XOvLSQ6SautW8DzSGCV8XKv9jQYlbM/4c3HwX
4vzIxYueW+u2MlfJZcYfkr8RK9bmk4mJCa63AK3VgRtQK21IJqNOR9lgiP202b+T
9o8CmT+rxAnEZHIr9j2nDjPlaR63lAWpSKsS/HxXr6wh2JS/34+YuhbvZlSrxYoR
D8Ta3fZYkIX7aCEziSNqRgZgz+VGroxrQCjdvTYRzr2G6LUVrr0D4dUJnBt1DhZO
klV+pv2tFl5q9szTuu0dkLNyPYFOTjCTD3GxpsuMwmONMAzsMUT+ouLVoklmXxim
Ah3ZrRv4O/hnjRZM0+tV498b4G8ZZmyp80K1CTQwLJNewpk9n2I2K7RVGFtyXa9M
irfOVbUQKaBTrqg=
-----END CERTIFICATE REQUEST-----
If my goal was only to verify integrity of a PEM file on two machines I could just use e.g. sha256sum csr.pem value but I'd like to get the same fingerprint as Puppet does
The general notion of the fingerprint/thumbprint of a certificate is a digest of the DER-encoded (binary) representation of the certificate. You can do this with the openssl x509 command directly... or indirectly:
$ openssl x509 -in test.cer -noout -sha256 -fingerprint
SHA256 Fingerprint=3E:A9:CB:54:36:DB:CF:23:50:D1:6B:D8:06:25:DC:0E:37:23:3E:A7:50:A5:D1:F3:05:0F:26:33:4E:F8:66:7C
$ openssl x509 -in test.cer -outform der | sha256sum
3ea9cb5436dbcf2350d16bd80625dc0e37233ea750a5d1f3050f26334ef8667c -
So the algorithm shouldn't require any private keys on input.
That is correct.
One of my failed attempts:
testbox:~# openssl x509 -fingerprint -in /etc/puppetlabs/puppet/ssl/certificate_requests/testbox.pem
Because the fingerprint/thumbprint is the digest of the signed certificate, it cannot be determined from the request. (The certificate has its validity information, the CA identifier, and the CA's signature... and probably extensions not present in the request.)
If you're trying to match a certificate to a certificate request, the only thing they're really guaranteed to have in common is the public key. If the -pubkey outputs match they're the same.
$ openssl req -in test.csr -pubkey -noout
-----BEGIN PUBLIC KEY-----
MIIBJDANBgkqhkiG9w0BAQEFAAOCAREAMIIBDAKCAQEAr4HBy9ggP2JKU57WYIF1
NyOTooN9SJDkihne02lzEVYglo1r4NPao4qnd74C7gtrk7ck6NzBK2MrT6gLvJJb
zmJPTKfMYGMGs5QD4oyTLSTdVG/+TvajfxB3CyIV6oy7W/Qn6MTYm3nrM4N1EAxf
g+Vd6bRGbd++7kJTmu8z7xh7d2DDsaGyEDwtgURWSgwQOaCchc9rWXTrUW/I1mI8
lK46WguztMeSlX1DI5FWbPPipSr7DBQrngaBuJcmca8rgt05Cjm5Oc9xlWhofkmQ
pjBQyndo3NazeIQvGP2x9tn/CWuve+uY3Pkw1m/P1QP1jUG/9GIS4k46/EXqQr2I
RwIFAgAABEE=
-----END PUBLIC KEY-----
$ openssl x509 -in test.cer -pubkey -noout
-----BEGIN PUBLIC KEY-----
MIIBJDANBgkqhkiG9w0BAQEFAAOCAREAMIIBDAKCAQEAr4HBy9ggP2JKU57WYIF1
NyOTooN9SJDkihne02lzEVYglo1r4NPao4qnd74C7gtrk7ck6NzBK2MrT6gLvJJb
zmJPTKfMYGMGs5QD4oyTLSTdVG/+TvajfxB3CyIV6oy7W/Qn6MTYm3nrM4N1EAxf
g+Vd6bRGbd++7kJTmu8z7xh7d2DDsaGyEDwtgURWSgwQOaCchc9rWXTrUW/I1mI8
lK46WguztMeSlX1DI5FWbPPipSr7DBQrngaBuJcmca8rgt05Cjm5Oc9xlWhofkmQ
pjBQyndo3NazeIQvGP2x9tn/CWuve+uY3Pkw1m/P1QP1jUG/9GIS4k46/EXqQr2I
RwIFAgAABEE=
-----END PUBLIC KEY-----
While I don't have an example offhand, just because they don't match doesn't mean they're different. This is because some algorithms, such as RSA, there are multiple different legal encodings for the key in SubjectPublicKeyInfo and the CA could re-normalize when signing the certificate.
For RSA you could open it with the openssl rsa command and then let OpenSSL re-normalize it (when writing it back out it won't remember which of the two representations were used)
$ openssl req -in test.csr -pubkey -noout | openssl rsa -pubin -outform der | sha256sum
writing RSA key
3305c9f5c37cb13c152d087eea65ce1af3f0f846b309cb0426f1f42ae5fcbae0 -
$ openssl x509 -in test.cer -pubkey -noout | openssl rsa -pubin -outform der | sha256sum
writing RSA key
3305c9f5c37cb13c152d087eea65ce1af3f0f846b309cb0426f1f42ae5fcbae0 -
IMHO, the answer of bartonjs didn't really answer woky's original question:
I've a certificate request (see bottom) of which I'd like get fingerprint preferably from command-line (Unix). [...] I'd like to get the same fingerprint as Puppet does
So the question was, how to get the same fingerprint of the CSR as puppet does internally.
This command should do the "magic" generating the same fingerprint.
openssl req -in /etc/puppetlabs/puppet/ssl/certificate_requests/testbox.pem -outform der | sha256sum | awk '{ print $1 }' | sed 's/\(..\)/\1:/g; s/:$//; s/./\U&/g;'
awk limits output to the sha256 string and sed re-formats the string (insert colons, all letters capital, remove ending colon). This will give you a representation of the CSR fingerprint how puppet outputs it.
Note: I haven't been able to generate the same fingerprint as woky provided in his initial question using his CSR. But I'm able to reconstruct a correct fingerprint with any CSR I generate my self, so I'd guess woky's CSR doesn't match the fingerprint provided in the question.
This is an modification of lars answer:
openssl req -in ./kontrollant.ca.csr.pem -outform DER|openssl dgst -sha256 -c
Though this gives the checksum in lower case, so awk or tr is possibilities
openssl req -in ./kontrollant.ca.csr.pem -outform DER|openssl dgst -sha256 -c|tr '[:lower:]' '[:upper:]'
Would be how i now would do this (i use the '-c' argument to openssl dgst's sha256)
Another method could be:
openssl req -in ./kontrollant.ca.csr.pem -outform DER|openssl dgst -sha256|awk '{ gsub(/../,"&:", $2); gsub(/:$/,"", $2); print upper($2) }'
I know there are many commands (openssl) to export pfx to pem BUT I need one thing different: I need to export the public key to a pem file and the private key to another file. Most of the commands and sites (some sites convert the pfx format to anyone I need) will only generate a single *.pem file.
Thanks.
Meta: this isn't a programming or development question, and will likely be closed as offtopic.
If you want the privatekey and the certificate (which contains the publickey but is not the publickey as such), this is a dupe of several questions in other Stacks where it is ontopic, including at least:
https://security.stackexchange.com/questions/3779/how-can-i-export-my-private-key-from-a-java-keytool-keystore/
https://serverfault.com/questions/715827/how-to-generate-key-and-crt-file-from-jks-file-for-httpd-apache-server
https://serverfault.com/questions/806141/is-the-alert-ssl3-read-bytessslv3-alert-bad-certificate-indicating-that-the-s (disclosure: my answer)
Alternatively since PEM files are structured text, you can parse the output of a single pkcs12 command by any number of text-handling programs such as awk:
openssl pkcs12 <p12 | awk '/-BEGIN ENC/,-END ENC/{print >"privkey"} \
/-BEGIN CERT/,/-END CERT/{if(!n)print >"cert"} /-END CERT/{n++}'
# for unencrypted privatekey add -nodes and select BEGIN/END PRIV
If you truly want the publickey, you can create it in algorithm-generic X.509 SubjectPublicKeyInfo form, from either the privatekey or the certificate:
# from the certificate
openssl x509 <certfile -noout -pubkey >pubkey
openssl pkcs12 <p12file -nokeys -clcerts | openssl x509 -noout -pubkey >pubkey
# from the privatekey
openssl pkey <privkey -pubout >pubkey
openssl pkcs12 <p12file -nocerts -nodes | openssl pkey -pubout >pubkey
This format is used by some OpenSSL functions (which calls it PUBKEY to distinguish from the several algorithm-specific PublicKey's), and low-level Java (which calls it X509EncodedKeySpec), and pretty much nothing else. Note systems using the bare public key are often insecure; that's exactly why most systems embed the publickey in a certificate.
If the key is RSA and you want the algorithm-specific (PKCS1 RSAPublicKey) format, in OpenSSL 1.1.0 (and presumably up) then use:
# from the SPKI publickey as above
openssl rsa <RSApub_spki [-inform DER] -pubin -RSAPublicKey_out [-outform DER] >RSApub_pkcs1
# from the privatekey
openssl rsa <RSAprivate [-inform DER] -RSAPublicKey_out [-outform DER] >RSApub_pkcs1
This is used rarely by a few OpenSSL functions and AFAIK nothing else; see caveat above.
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
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