I'm using OpenSSL to generate keys/csrs/certs. I'm using a openssl.cnf file to add extensions to these certifications.
How do I check if a completed cert has the extensions that I requested using OpenSSL's command line?
I've tried this line of code:
openssl x509 -in certificate.crt -text -noout
But it doesn't show the extensions. I've also fiddled around with verify, but it doesn't work either.
I'm looking to check the values of these extensions: basicConstraints, keyUsage, serverAuth
Thanks
openssl x509 -in certificate.crt -text -noout
But it doesn't show the extensions
If this does not show the extensions then there are probably no extensions in your certificate. If you take for instance the certificate you get when visiting paypal.com the command line above will give you lots of extensions, like:
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:history.paypal.com, DNS:t.paypal.com, ...
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
...
Related
I am trying to generate a certificate-(authority)-chain, where some intermediates have specific tasks.
There will be a root certificate (skipped for testing) that signs the actual CA, this CA on the one hand, signs a CA that should only be able to sign client-certificates, and on the other hand, signs one/multiple CA's that can only perform server-certificates-signing. The idea is, that this "server-ca" will be deployed into an embedded system in order to create a new server certificate with different sans if nescessary, but should not be able to sign client-certificates. (see my fine drawing)
I did not find much about constraining a ca. Here it says it would be possible, so I tried to create a test setup where I defined an extendedKeyUsage for the device/server-CA. The X509v3 extensions in the certs I created look like the following
Server/Device-CA:
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE <-(yeah, forgot 'bout the path-length - hope this is not the problem)
X509v3 Subject Key Identifier:
51:0F:8C:55:88:4D:3E:25:DC:EC:6D:73:39:E4:7D:27:2E:AF:E4:2D
X509v3 Authority Key Identifier:
keyid:B3:6A:53:D9:9B:CF:74:69:B5:64:73:91:D7:18:92:30:E3:A7:7A:A6
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Extended Key Usage: critical
TLS Web Server Authentication <--
Server/Device-CA -> Server-Cert
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
OpenSSL Generated Server Certificate
X509v3 Subject Key Identifier:
AD:BC:E0:73:50:AB:7F:BE:3C:43:71:4F:07:06:D8:3F:1A:38:81:4C
X509v3 Authority Key Identifier:
keyid:51:0F:8C:55:88:4D:3E:25:DC:EC:6D:73:39:E4:7D:27:2E:AF:E4:2D
DirName:/C=XXX/ST=XXX/L=XX/O=XXX/OU=XXX/CN=XXX/emailAddress=XXX
serial:10:00
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication <--
Server/Device-CA -> Client-Cert
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME
Netscape Comment:
OpenSSL Generated Client Certificate
X509v3 Subject Key Identifier:
AD:BC:E0:73:50:AB:7F:BE:3C:43:71:4F:07:06:D8:3F:1A:38:81:4C
X509v3 Authority Key Identifier:
keyid:51:0F:8C:55:88:4D:3E:25:DC:EC:6D:73:39:E4:7D:27:2E:AF:E4:2D
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, E-mail Protection <--
Anyway when I use openssl verify it says both certificates were valid. I hope you can help me.
Thank you
A simple openssl verify does not know that the leaf certificate should be used as a client certificate. That's why it will not take the purpose of the certificates into account when validating the trust chain:
$ openssl verify -CAfile root.pem -untrusted middle.pem client.pem
client.pem: OK
With an explicitly given purpose of sslclient it fails instead:
$ openssl verify -purpose sslclient -CAfile root.pem -untrusted middle.pem client.pem
CN = middle
error 26 at 1 depth lookup: unsupported certificate purpose
error client.pem: verification failed
Having a different intermediate certificate which has sslclient as purpose to it instead succeeds:
$ openssl verify -purpose sslclient -CAfile root.pem -untrusted alt-middle.pem client.pem
client.pem: OK
I found a easy tutorial which explains a few steps to create a own self signed ca.crt which can be used to sign keys for a mqtt broker:
http://www.steves-internet-guide.com/mosquitto-tls/
That is a great tutorial but some librarys need to have a set subjectAltName in the .crt.
So i followed: http://wiki.cacert.org/FAQ/subjectAltName and created a server.csr with the
Requested Extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Subject Alternative Name:
DNS:127.0.0.1, DNS:localhost
Now I have problems with the last step. How can I use the ca.crt and ca.key to generate a server.crt from the server.csr (with the extensions) ?
Hope for your help ;)
T
I'm not sure what the right terminology is, but I am generating an ssl cert signed by my own CA using the openssl "ca" command. When I do, I get a .pem file with a "header" which looks something like this:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e9:f1:6b:ab:c8:ea:25:06
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=SomeWhere, L=SomeWhere, O=MyCompany, OU=Software Development, CN=test.com Certifying Authority/emailAddress=certsref#test.com
Validity
Not Before: Apr 21 22:41:51 2018 GMT
Not After : Apr 20 22:41:51 2068 GMT
Subject: C=US, ST=SomeWhere, O=MyCompany, OU=Software Development, CN=test.com/emailAddress=certsref#test.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:de:59:c8:02:18:b4:f5:05:70:37:5a:ba:d7:3c:
...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
D9:71:FB:D3:45:AD:85:23:A9:0B:5D:93:CD:AB:56:EE:D1:B3:41:29
X509v3 Authority Key Identifier:
keyid:84:37:2F:10:E4:03:9A:6A:BF:21:B1:AF:37:DA:E9:1F:BF:68:78:B1
X509v3 Subject Alternative Name:
DNS:test.com, DNS:192.168.100.1, IP Address:192.168.100.1
Signature Algorithm: sha256WithRSAEncryption
aa:3e:52:88:4f:ef:03:37:64:2e:da:46:f3:e1:b0:60:35:03:
...
-----BEGIN CERTIFICATE-----
MIIEszCCA5ugAwIBAgIJAOnxa6vI6iUGMA0GCSqGSIb3DQEBCwUAMIHGMQswCQYD
...
-----END CERTIFICATE-----
I can strip that file down to just the base 64 part (i.e. remove the "header") by using:
openssl x509 -in in.pem -inform PEM -out out.pem -outform PEM
My question is, how do I do the reverse? How do I add this "header" info or explicitly generate my CA cert with that?
When I generate my CA, I use:
openssl req -x509 ...
This produces a pem WITHOUT the header. I'd like to have my CA pem WITH a header as well, so I can have a CA and a cert signed by it which both have headers.
I got it myself. Sometimes (frequently...) asking the question pushes me in the right direction.
The "header" I was referring turned out to be the certificate in "text format". This can be output by running the following:
openssl x509 -in cacert.pem -text -noout
So, I just ran that on my "headless" CA, got the text and preppended it on the file itself. As far as I can see, the CA cert still works perfectly (for those contexts which are fine with the "header" being present).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I am trying to generate a self-signed certificate with OpenSSL with SubjectAltName in it.While I am generating the csr for the certificate, my guess is I have to use v3 extensions of OpenSSL x509.
I am using :
openssl req -new -x509 -v3 -key private.key -out certificate.pem -days 730
Can someone help me with the exact syntax?
Can someone help me with the exact syntax?
It's a three-step process, and it involves modifying the openssl.cnf file. You might be able to do it with only command line options, but I don't do it that way.
Find your openssl.cnf file. It is likely located in /usr/lib/ssl/openssl.cnf:
$ find /usr/lib -name openssl.cnf
/usr/lib/openssl.cnf
/usr/lib/openssh/openssl.cnf
/usr/lib/ssl/openssl.cnf
On my Debian system, /usr/lib/ssl/openssl.cnf is used by the built-in openssl program. On recent Debian systems it is located at /etc/ssl/openssl.cnf
You can determine which openssl.cnf is being used by adding a spurious XXX to the file and see if openssl chokes.
First, modify the req parameters. Add an alternate_names section to openssl.cnf with the names you want to use. There are no existing alternate_names sections, so it does not matter where you add it.
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
Next, add the following to the existing [ v3_ca ] section. Search for the exact string [ v3_ca ]:
subjectAltName = #alternate_names
You might change keyUsage to the following under [ v3_ca ]:
keyUsage = digitalSignature, keyEncipherment
digitalSignature and keyEncipherment are standard fare for a server certificate. Don't worry about nonRepudiation. It's a useless bit thought up by computer science guys/gals who wanted to be lawyers. It means nothing in the legal world.
In the end, the IETF (RFC 5280), browsers and CAs run fast and loose, so it probably does not matter what key usage you provide.
Second, modify the signing parameters. Find this line under the CA_default section:
# Extension copying option: use with caution.
# copy_extensions = copy
And change it to:
# Extension copying option: use with caution.
copy_extensions = copy
This ensures the SANs are copied into the certificate. The other ways to copy the DNS names are broken.
Third, generate your self-signed certificate:
$ openssl genrsa -out private.key 3072
$ openssl req -new -x509 -key private.key -sha256 -out certificate.pem -days 730
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
...
Finally, examine the certificate:
$ openssl x509 -in certificate.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 9647297427330319047 (0x85e215e5869042c7)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=MD, L=Baltimore, O=Test CA, Limited, CN=Test CA/emailAddress=test#example.com
Validity
Not Before: Feb 1 05:23:05 2014 GMT
Not After : Feb 1 05:23:05 2016 GMT
Subject: C=US, ST=MD, L=Baltimore, O=Test CA, Limited, CN=Test CA/emailAddress=test#example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (3072 bit)
Modulus:
00:e2:e9:0e:9a:b8:52:d4:91:cf:ed:33:53:8e:35:
...
d6:7d:ed:67:44:c3:65:38:5d:6c:94:e5:98:ab:8c:
72:1c:45:92:2c:88:a9:be:0b:f9
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
34:66:39:7C:EC:8B:70:80:9E:6F:95:89:DB:B5:B9:B8:D8:F8:AF:A4
X509v3 Authority Key Identifier:
keyid:34:66:39:7C:EC:8B:70:80:9E:6F:95:89:DB:B5:B9:B8:D8:F8:AF:A4
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment, Certificate Sign
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com, DNS:mail.example.com, DNS:ftp.example.com
Signature Algorithm: sha256WithRSAEncryption
3b:28:fc:e3:b5:43:5a:d2:a0:b8:01:9b:fa:26:47:8e:5c:b7:
...
71:21:b9:1f:fa:30:19:8b:be:d2:19:5a:84:6c:81:82:95:ef:
8b:0a:bd:65:03:d1
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.