When creating CSR, since the conf can take country and state info, I assume it will be embedded in the certificate. If so, how to display it after the certificate is signed? I tried "$ openssl x509 -in foo.crt -noout -text" but seems the information is not there. I also checked "-help". Any other way to print? Thanks a lot.
More found: it seems country and state information is removed when CSR is signed, correct?
For example, this is what I observe.
$ openssl req -text -noout -in server.csr
Certificate Request:
Data:
Version: 0 (0x0)
Subject: Subject: DC=..., DC=..., C=..., ST=..., L=..., O=..., OU=..., CN=...
...
$ openssl x509 -text -noout -in server.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: DC=..., DC=..., O=..., OU=..., CN=...
Validity
Not Before: Dec 5 22:05:21 2013 GMT
Not After : Dec 5 22:05:21 2015 GMT
Subject: DC=..., DC=..., O=..., OU=..., CN=...
As seen, the fields of "C", "ST" and "L" in the Subject are missing in certificate.
You would use the same command you are already using (if you only care about subject information, you could use openssl x509 -subject -noout -in server.crt, replacing -text with -subject). The problem in your case is that, as you noted, the city and state information was removed by the signer. What information to place into the certificate is ultimately the prerogative of the issuer.
Country and state information is under Subject and in C and ST field respectively.
As per my knowledge, issuer does not remove any information present in CSR.
Display the contents of a SSL certificate:
openssl x509 -in certificate.crt -text -noout
Related
As should be clear, I am a newbie to certificates and cryptography in general.
I am trying to generate self-signed certificates programmatically for use with WebRTC in the implementation of a SFU. The RFC at Section 4.9, on the subject of certificates used for WebRTC, states:
The following values MUST be supported by a user agent: { name:
"RSASSA-PKCS1-v1_5", modulusLength: 2048, publicExponent: new
Uint8Array([1, 0, 1]), hash: "SHA-256" }, and { name: "ECDSA",
namedCurve: "P-256" }.
After creating an ECDSA cert programmatically in C and saving it, I run the following command on the certificate file created:
openssl x509 -in /tmp/ecdsa_certificate -text #Linux command-line
I get the output:
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 1 (0x1)
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = IN, O = XYZ Tech., CN = localhost
Validity
Not Before: Jun 23 17:28:14 2020 GMT
Not After : Jun 23 17:28:14 2021 GMT
Subject: C = IN, O = XYZ Tech., CN = localhost
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:d9:c8:cc:93:13:54:3d:e6:40:d7:2f:33:da:f2:
d4:e4:62:83:a4:ec:ad:98:f5:d5:2e:cf:3b:e8:5f:
ad:da:b9:e0:59:f0:19:59:84:b8:47:45:b4:21:56:
30:c8:1d:0b:9b:2d:02:e2:f5:4d:c7:57:2e:e6:a6:
f9:c4:c4:a7:5c
ASN1 OID: secp256k1
Signature Algorithm: ecdsa-with-SHA256
30:44:02:20:58:0a:49:7d:e3:0f:d7:56:6a:5c:af:f8:bd:1d:
5e:54:bb:15:10:ec:05:3a:3a:db:79:8f:e6:70:86:6d:3d:f1:
02:20:4f:89:5f:df:21:46:1b:da:6b:40:04:98:2c:df:35:ff:
e5:3d:52:d5:07:76:bf:23:a4:01:b7:28:bf:f5:83:30
-----BEGIN CERTIFICATE-----
MIIBTTCB9QIBATAKBggqhkjOPQQDAjA1MQswCQYDVQQGEwJJTjESMBAGA1UECgwJ
WFlaIFRlY2guMRIwEAYDVQQDDAlsb2NhbGhvc3QwHhcNMjAwNjIzMTcyODE0WhcN
MjEwNjIzMTcyODE0WjA1MQswCQYDVQQGEwJJTjESMBAGA1UECgwJWFlaIFRlY2gu
MRIwEAYDVQQDDAlsb2NhbGhvc3QwVjAQBgcqhkjOPQIBBgUrgQQACgNCAATZyMyT
E1Q95kDXLzPa8tTkYoOk7K2Y9dUuzzvoX63aueBZ8BlZhLhHRbQhVjDIHQubLQLi
9U3HVy7mpvnExKdcMAoGCCqGSM49BAMCA0cAMEQCIFgKSX3jD9dWalyv+L0dXlS7
FRDsBTo623mP5nCGbT3xAiBPiV/fIUYb2mtABJgs3zX/5T1S1Qd2vyOkAbcov/WD
MA==
-----END CERTIFICATE-----
Does this certificate comply with the requirements of WebRTC for DTLS handshaking. It appears that only the public key and the fingerprint of the certificate matters for WebRTC usage.
Question 2:
I tried to compute the fingerprint over the certificate using the following function:
if (X509_digest(certificate, EVP_sha256(), rfingerprint, &fingerprintSize) !=0 )
printf("Error in X509_digest\n");
printf("finger print size is %d\n", fingerprintSize);
It displays a fingerprint size of only 7! In most of the SDPs I see that the fingerprint attribute is a lot longer. Any comments?
When working on Pion I was in the same boat as you asinix :) This is what I use to generate locally when testing WebRTC stuff.
openssl ecparam -out key.pem -name prime256v1 -genkey
openssl req -new -sha256 -key key.pem -out server.csr
openssl x509 -req -sha256 -days 365 -in server.csr -signkey key.pem -out cert.pem
If you get stuck you can also do RSA! Maybe just to unblock you on building your MVP :)
The implementation is Pure Go now, but you can see the first version where we did CGO here
I am not sure where your stuff differs, but feel free to copy/compare (no attribution needed)!
If I use OpenSSL to create an X509 certificate that gets signed with a CA certificate and includes an X509v3 SAN (Subject Alternative Name) extension, the generated certificate contains the SAN extension twice, whereas if the certificate is self-signed the SAN extension appears only once (which I would consider correct).
Steps to reproduce:
$ openssl version
OpenSSL 1.0.2n 7 Dec 2017
$ openssl genrsa -out example.key 2048
$ openssl req -new -key example.key -out example.csr
# ... confirm certificate defaults only enter "example.com" as Common Name
$ echo subjectAltName=DNS:example.com,DNS:www.example.com > example.cnf
$ openssl x509 -req -sha256 -days 7300 -text -extfile example.cnf \
-in example.csr -signkey example.key \
-CA ../ca.crt -CAkey ../ca.key -set_serial 01 \
-out example.crt
Afterwards if I inpect the certificate the section "X509v3 Subject Alternative Name" is printed twice:
$ openssl x509 -in example.crt -text -noout
...
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com
...
This is not the case if no CA is used and the certificate gets self-signed via:
$ openssl x509 -req -sha256 -days 7300 -text -extfile example.cnf \
-in example.csr -signkey example.key \
-out example.crt
I can verify this behavior with OpenSSL 1.0.2n as well as OpenSSL 0.9.8zh.
Is this an OpenSSL bug or is there any valid explanation for this?
See answer of #dave_thompson_085:
Using both -signkey and -CAkey does not make any sense and triggers this strange side-effect.
When using OpenSSL utils for signing .csr request, its possible to use "openssl ca" util and "openssl x509" util.
Openssl ca's text config file has all needed x509 options like keyUsage, extendedKeyUsage.
Openssl x509's command line has options -addtrust and -addreject. When you sign a certificate with those options, you can see them later in "openssl x509 -text" output, something like:
user#inet-pc:~$ openssl x509 -req -in test.csr -CA ca.crt -CAkey ca.key -set_serial 1 -out test.crt -setalias "zzzz test alias" -addtrust emailProtection -addreject serverAuth
^ signing test.csr using own CA key and cert
user#inet-pc:~$ openssl x509 -text -in test.crt -nooutCertificate:
Data:
Version: 1 (0x0)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=RU, ST=Some-State, O=Internet Widgits Pty Ltd, OU=sdds, CN=ca
Validity
Not Before: Apr 23 06:24:58 2013 GMT
Not After : May 23 06:24:58 2013 GMT
Subject: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=test
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
(huge text here)
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
(huge text here)
Trusted Uses:
E-mail Protection
Rejected Uses:
TLS Web Server Authentication
Alias: zzzz test alias
^ Trusted and Rejected uses. What are those uses for and how do they work? Why I cannot find any mention of them in X509 RFC5280? How to use "openssl ca" to add same trusted/rejected uses? What about "clientAuth" usage? It isnt listed in "trusted" or "rejected" - will this certificate be trusted by most common applications?
Update 1: OpenSSL's x509 manual says that "trust" settings are valid for OpenSSL's "verify" util, but what is that util for? Can invalid "trust" settings cause verification fail by usual http browsers/etc?
You need to look at the section 4.2.1.12 "Extended Key Usage" of the rfc5280 :
https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12
Edit:
You are right, I am afraid I read your question too quickly. The trust settings are an OpenSSL auxiliary information, which as far as I know is stil experimental. See :
https://www.openssl.org/docs/apps/x509.html#TRUST_SETTINGS
Again, I am sorry for my previous answer.
I have a SSL certificate. I want to check if the certificate is intact or corrupted. Are there any tool to check this?
Problem is we are unable to get this certificate working in Websphere 8.0 and I was thinking if this cert file could be corrupted.
Yes, you can check a certificate with openssl (available for windows and *nix).
openssl x509 -in certificate.crt -text -noout
Reference
Update
To be more precise, you can compare the modulus and public exponent of the key and certificate respectively to guarantee that certificate matches the key and that the certificate has not been corrupted.
openssl rsa -noout -modulus -in server.key.pem | openssl sha1;\
openssl x509 -noout -modulus -in server.crt | openssl sha1
Valid output would look like
7298b69426656f7a8ab3ef9686bc0a79588850e7
7298b69426656f7a8ab3ef9686bc0a79588850e7
After hand modifying the cert the output would be.
7298b69426656f7a8ab3ef9686bc0a79588850e7
bd439a18d2d3689470e209dbd45b85a41db7230c
The command
openssl x509 -in certificate.crt -text -noout
is used for verifying certificate chains but not checking for corruption. A hand modified certificate could return valid looking output but a problem with the RSA Public Key: (4096 bit) Modulus (4096 bit): part would only be detectable with the above check.
Another Reference
I am signing packets in some Java code and I want to verify the signatures on a C server. I want to fork openssl for this purpose (can always use library functions later... when I know openssl can verify the signatures); however, it's failing to do so:
openssl dgst -verify cert.pem -signature file.sha1 file.data
all it says is "unable to load key file"
The certificate says:
openssl verify cert.pem
cert.pem: /C=....
error 20 at 0 depth lookup:unable to get local issuer certificate
However, I specifically don't care about verifying the certificate, I want only to verify the signature for a given file!
The output of openssl x509 -in cert.pem -noout -text is:
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
...
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=...
Validity
Not Before: Feb 1 15:22:44 2010 GMT
Not After : Jun 19 15:22:44 2037 GMT
Subject: C=...
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:cc:cc:f9:c7:3a:00:0f:07:90:55:d9:fb:a9:fe:
...
32:cc:ee:7f:f2:01:c7:35:d2:b5:9b:35:dd:69:76:
00:a9
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
39:d6:2c:6b:6a:00:74:b5:81:c2:b8:60:d6:6b:54:11:41:8d:
...
8f:3e:3f:5d:b3:f8:dd:5e
openssl dgst -verify foo.pem expects that foo.pem contains the "raw" public key in PEM format. The raw format is an encoding of a SubjectPublicKeyInfo structure, which can be found within a certificate; but openssl dgst cannot process a complete certificate in one go.
You must first extract the public key from the certificate:
openssl x509 -pubkey -noout -in cert.pem > pubkey.pem
then use the key to verify the signature:
openssl dgst -verify pubkey.pem -signature sigfile datafile