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.
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)!
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).
After spending two days searching and finding answers to my questions only to realize these answers were only creating more questions and problems I couldn't solve, I resolved to ask for help here hoping I hadn't missed the information I'm looking for somewhere.
I've just began a project in which I have to exchange X.509 certificates with a client before starting to work with this client.
I've managed to understand well how and why X.509 certificate were made :
Make a CSR from a private key;
This CSR contains digital identity and a public key extracted from private key;
CSR is self-signed or sent to a CA who signs it with its own private key in order to validate the identity of the sender;
The CA sends back a certificate matching X.509 standard and proving you're not faking an identity and thus that the public key contained in X.509 is reliable.
So X.509 certificate is a way to exchange your public key with someone in order to counter a potential man-in-the-middle attack.
Using OpenSSL I've been able to simulate alone those operations in order to understand the functioning of these steps.
My first problem is that when I make a CSR from a private key (privateKey.pem) and then check if this private key matches the CSR, it doesn't.
I then self-sign the CSR with a different private key (signingPrivateKey.pem), check again if the X.509 certificate matches the private key, and it still does not (which seems normal because the CSR didn't either but both should match, shouldn't they ?).
Here are the OpenSSL commands :
#echo off
echo "Generates private key and puts it in SigningPrivateKey.pem"
echo.
openssl genrsa -out SigningPrivateKey.pem 1024
echo "Generates private key and puts it in privateKey.pem, then create CSR"
echo.
openssl req -newkey rsa:1024 -keyout privateKey.pem -out CSR_TEST.csr -nodes
echo "Checks if CSR and privateKey matches
echo.
openssl x509 -noout -modulus -in CSR_TEST.csr | openssl md5
openssl rsa -noout -modulus -in privateKey.pem | openssl md5
echo "Self sign CSR with private key"
echo.
openssl x509 -in CSR_TEST.csr -out CSR_TEST.pem -req -signkey
SigningPrivateKey.pem -days 1
echo. "Checks again if certificate and private key matches
openssl x509 -noout -modulus -in CSR_TEST.pem | openssl md5
openssl rsa -noout -modulus -in privateKey.pem | openssl md5
Here's the summarized input :
stdin = d41d8....8427e
stdin = f3213....4538c
Signature ok
stdin = 82baf...a0863
stdin = f3213...4538c
My second problem is the way to verify a X.509.
Let's say I manage to make a X.509 certificate from an input private key and the extracted public key matches with it. I send it to my client, who sends a certificate to.
How do we know this X.509 is reliable ? I've read somewhere that we need to "unsign" the X.509 certificate with the CA's public key, and compare the output with a hashed certificate, but everyone seems to say that an X.509 certificate is self-sufficient and that it proves by itself your identity. We'd just need to check its authenticity with an OpenSSL command ?
Please lighten me on this point.
Thanks for taking the time to read and understand my problems, once again I hope I'm not the only one facing those problems and that this post will help someone else.
Sorry for I'm not allowed yet to put more links in this post, otherwise I'd have been more accurate.
CSR/Key comparison
$ openssl req -in test.csr -modulus -noout | openssl md5
(stdin)= 76d44c1a05f535f5e78a648b41bdaf73
$ openssl rsa -in test.key -modulus -noout | openssl md5
(stdin)= 76d44c1a05f535f5e78a648b41bdaf73
You used openssl x509 on a CSR. They're not the same. And you clearly didn't look at the output before running it through MD5:
$ openssl x509 -in test.csr -modulus -noout
unable to load certificate
139958187611800:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:701:Expecting: TRUSTED CERTIFICATE
You haven't made it into a certificate yet, so the x509 command doesn't work.
Your after you do make the certificate and you check again, you're getting a different answer because you used -signkey. The documentation says that -signkey is used as a self-sign key, meaning it replaces the public key that was in the original request. If you use -signkey privateKey.pem your commands should show alignment.
Integrity
Each X.509 certificate contains the presented data (including the public key) and a signature. For "real" CAs there's usually a note (the Authority Information Access extension) which says how to find the CA's certificate. Whether you have it on-hand or you have to go retrieve it from the internet, the public key in the signing certificate can be used to validate that the data in the original certificate hasn't changed.
The signing CA itself had a certificate, so you can go another step and prove that it hasn't been altered.
Eventually you get to a root/self-signed certificate. Either you already have it and consider it trusted, or you don't, and you call the whole thing malarkey.
The only thing that can really be verified about a self-signed certificate which isn't part of your inbuilt trust store is that it wasn't modified after it was created. The only security benefit of this is repudiation: If someone edited a certificate you created and added an extension which says something to the effect of "Your mother is a smelly donkey salesman!" you can demonstrate that the self-signed signature is invalid.
$ openssl x509 -in test.cer -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 11195357966677484939 (0x9b5de6c15126a58b)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, OU=.NET Framework (CoreFX), CN=localhost
Validity
Not Before: Mar 2 01:48:00 2016 GMT
Not After : Mar 2 01:48:00 2017 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, OU=.NET Framework (CoreFX), CN=localhost
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:af:81:c1:cb:d8:20:3f:62:4a:53:9e:d6:60:81:
75:37:23:93:a2:83:7d:48:90:e4:8a:19:de:d3:69:
73:11:56:20:96:8d:6b:e0:d3:da:a3:8a:a7:77:be:
02:ee:0b:6b:93:b7:24:e8:dc:c1:2b:63:2b:4f:a8:
0b:bc:92:5b:ce:62:4f:4c:a7:cc:60:63:06:b3:94:
03:e2:8c:93:2d:24:dd:54:6f:fe:4e:f6:a3:7f:10:
77:0b:22:15:ea:8c:bb:5b:f4:27:e8:c4:d8:9b:79:
eb:33:83:75:10:0c:5f:83:e5:5d:e9:b4:46:6d:df:
be:ee:42:53:9a:ef:33:ef:18:7b:77:60:c3:b1:a1:
b2:10:3c:2d:81:44:56:4a:0c:10:39:a0:9c:85:cf:
6b:59:74:eb:51:6f:c8:d6:62:3c:94:ae:3a:5a:0b:
b3:b4:c7:92:95:7d:43:23:91:56:6c:f3:e2:a5:2a:
fb:0c:14:2b:9e:06:81:b8:97:26:71:af:2b:82:dd:
39:0a:39:b9:39:cf:71:95:68:68:7e:49:90:a6:30:
50:ca:77:68:dc:d6:b3:78:84:2f:18:fd:b1:f6:d9:
ff:09:6b:af:7b:eb:98:dc:f9:30:d6:6f:cf:d5:03:
f5:8d:41:bf:f4:62:12:e2:4e:3a:fc:45:ea:42:bd:
88:47
Exponent: 8589935681 (0x200000441)
X509v3 extensions:
X509v3 Subject Key Identifier:
78:A5:C7:5D:51:66:73:31:D5:A9:69:24:11:4C:9B:5F:A0:0D:7B:CB
X509v3 Authority Key Identifier:
keyid:78:A5:C7:5D:51:66:73:31:D5:A9:69:24:11:4C:9B:5F:A0:0D:7B:CB
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
77:75:6d:05:ff:a6:ad:fe:d5:b6:d4:af:b5:40:84:0c:6d:01:
cf:6b:3f:a6:c9:73:df:d6:1f:ca:a0:a8:14:fa:1e:24:69:01:
9d:94:b1:d8:56:d0:7d:d2:b9:5b:85:50:df:d2:08:59:53:a4:
94:b9:9e:fc:ba:a7:98:2c:e7:71:98:4f:9d:4a:44:5f:fe:e0:
62:e8:a0:49:73:6a:39:fd:99:4e:1f:da:0a:5d:c2:b5:b0:e5:
7a:0b:10:c4:1b:c7:fe:6a:40:b2:4f:85:97:73:02:59:3e:60:
b9:8d:d4:81:1d:47:d9:48:ed:f8:d6:e6:b5:af:80:a1:82:74:
96:e2:0b:fd:24:0e:46:76:74:50:4d:4e:47:03:33:1d:64:70:
5c:36:fb:6e:14:ba:bf:d9:cb:ee:c4:4b:33:a8:d7:b3:64:79:
90:0f:3c:5b:ba:b6:9c:5e:45:3d:18:07:83:e2:50:80:51:b9:
98:c0:38:e4:62:25:71:d2:ab:89:1d:89:8e:54:58:82:8c:f1:
86:79:51:7d:28:db:ca:bf:72:e8:13:07:bf:d7:21:b7:3d:db:
17:51:12:3f:99:d8:fc:0d:53:37:98:c4:db:d1:47:19:d5:d8:
a8:5b:00:a1:44:a3:67:67:7b:48:89:1a:9b:56:f0:45:33:48:
11:ba:cb:7a
And
$ openssl x509 -in alsotest.cer -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 11195357966677484939 (0x9b5de6c15126a58b)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, OU=.NET Framework (CoreFX), CN=localhost
Validity
Not Before: Mar 2 01:48:00 2016 GMT
Not After : Mar 2 01:48:00 2019 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, OU=.NET Framework (CoreFX), CN=localhost
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:af:81:c1:cb:d8:20:3f:62:4a:53:9e:d6:60:81:
75:37:23:93:a2:83:7d:48:90:e4:8a:19:de:d3:69:
73:11:56:20:96:8d:6b:e0:d3:da:a3:8a:a7:77:be:
02:ee:0b:6b:93:b7:24:e8:dc:c1:2b:63:2b:4f:a8:
0b:bc:92:5b:ce:62:4f:4c:a7:cc:60:63:06:b3:94:
03:e2:8c:93:2d:24:dd:54:6f:fe:4e:f6:a3:7f:10:
77:0b:22:15:ea:8c:bb:5b:f4:27:e8:c4:d8:9b:79:
eb:33:83:75:10:0c:5f:83:e5:5d:e9:b4:46:6d:df:
be:ee:42:53:9a:ef:33:ef:18:7b:77:60:c3:b1:a1:
b2:10:3c:2d:81:44:56:4a:0c:10:39:a0:9c:85:cf:
6b:59:74:eb:51:6f:c8:d6:62:3c:94:ae:3a:5a:0b:
b3:b4:c7:92:95:7d:43:23:91:56:6c:f3:e2:a5:2a:
fb:0c:14:2b:9e:06:81:b8:97:26:71:af:2b:82:dd:
39:0a:39:b9:39:cf:71:95:68:68:7e:49:90:a6:30:
50:ca:77:68:dc:d6:b3:78:84:2f:18:fd:b1:f6:d9:
ff:09:6b:af:7b:eb:98:dc:f9:30:d6:6f:cf:d5:03:
f5:8d:41:bf:f4:62:12:e2:4e:3a:fc:45:ea:42:bd:
88:47
Exponent: 8589935681 (0x200000441)
X509v3 extensions:
X509v3 Subject Key Identifier:
78:A5:C7:5D:51:66:73:31:D5:A9:69:24:11:4C:9B:5F:A0:0D:7B:CB
X509v3 Authority Key Identifier:
keyid:78:A5:C7:5D:51:66:73:31:D5:A9:69:24:11:4C:9B:5F:A0:0D:7B:CB
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
77:75:6d:05:ff:a6:ad:fe:d5:b6:d4:af:b5:40:84:0c:6d:01:
cf:6b:3f:a6:c9:73:df:d6:1f:ca:a0:a8:14:fa:1e:24:69:01:
9d:94:b1:d8:56:d0:7d:d2:b9:5b:85:50:df:d2:08:59:53:a4:
94:b9:9e:fc:ba:a7:98:2c:e7:71:98:4f:9d:4a:44:5f:fe:e0:
62:e8:a0:49:73:6a:39:fd:99:4e:1f:da:0a:5d:c2:b5:b0:e5:
7a:0b:10:c4:1b:c7:fe:6a:40:b2:4f:85:97:73:02:59:3e:60:
b9:8d:d4:81:1d:47:d9:48:ed:f8:d6:e6:b5:af:80:a1:82:74:
96:e2:0b:fd:24:0e:46:76:74:50:4d:4e:47:03:33:1d:64:70:
5c:36:fb:6e:14:ba:bf:d9:cb:ee:c4:4b:33:a8:d7:b3:64:79:
90:0f:3c:5b:ba:b6:9c:5e:45:3d:18:07:83:e2:50:80:51:b9:
98:c0:38:e4:62:25:71:d2:ab:89:1d:89:8e:54:58:82:8c:f1:
86:79:51:7d:28:db:ca:bf:72:e8:13:07:bf:d7:21:b7:3d:db:
17:51:12:3f:99:d8:fc:0d:53:37:98:c4:db:d1:47:19:d5:d8:
a8:5b:00:a1:44:a3:67:67:7b:48:89:1a:9b:56:f0:45:33:48:
11:ba:cb:7a
To spare you the eye strain: One of them has an expiration in the current past, another has an expiration date in the current future. (I was too lazy to inject an extension).
Which one is correct?
$ openssl verify test.cer
test.cer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, OU = .NET Framework (CoreFX), CN = localhost
error 18 at 0 depth lookup:self signed certificate
C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, OU = .NET Framework (CoreFX), CN = localhost
error 10 at 0 depth lookup:certificate has expired
OK
$ openssl verify alsotest.cer
alsotest.cer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, OU = .NET Framework (CoreFX), CN = localhost
error 18 at 0 depth lookup:self signed certificate
OK
Drat, they're both correct. Or are they? Wait, openssl verify doesn't check self-signed signatures normally, because it usually doesn't matter.
$ openssl verify -check_ss_sig test.cer
test.cer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, OU = .NET Framework (CoreFX), CN = localhost
error 18 at 0 depth lookup:self signed certificate
C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, OU = .NET Framework (CoreFX), CN = localhost
error 10 at 0 depth lookup:certificate has expired
OK
$ openssl verify -check_ss_sig alsotest.cer
alsotest.cer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, OU = .NET Framework (CoreFX), CN = localhost
error 18 at 0 depth lookup:self signed certificate
C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, OU = .NET Framework (CoreFX), CN = localhost
error 7 at 0 depth lookup:certificate signature failure
140450704717464:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
140450704717464:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
There we go. alsotest.cer was modified (without being resigned) to extend its expiration date.
I wish to sign a .mobileconfig file using the following command:
openssl smime \
-sign \
-signer your-cert.pem \
-inkey your-priv-key.pem \
-certfile TheCertChain.pem \
-nodetach \
-outform der \
-in ConfigProfile.mobileconfig \
-out ConfigProfile_signed.mobileconfig
I have an SSL certificate which was requested and installed on my machine, and a code-signing certificate which was requested and installed on my machine.
Now which certificate should I be using (code signing or SSL?), and how do I get hold of the your-cert.pem,your-priv-key.pem and TheCertChain.pem files?
Visiting GoDaddy again just gives me a single .pem file, and I do not know which one that even is.
Running openssl x509 -in godaddy.pem -inform pem -noout -text on the .pem from GoDaddy gives the following:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority
Validity
Not Before: Jun 29 17:06:20 2004 GMT
Not After : Jun 29 17:06:20 2034 GMT
Subject: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:de:9d:d7:ea:57:18:49:a1:5b:eb:d7:5f:48:86:
ea:be:dd:ff:e4:ef:67:1c:f4:65:68:b3:57:71:a0:
****REMOVED FOR BREVITY****
58:c6:44:7b:0a:3e:62:28:5f:ba:41:07:53:58:cf:
11:7e:38:74:c5:f8:ff:b5:69:90:8f:84:74:ea:97:
1b:af
Exponent: 3 (0x3)
X509v3 extensions:
X509v3 Subject Key Identifier:
D2:C4:****REMOVED FOR BREVITY****:A8:6A:D4:E3
X509v3 Authority Key Identifier:
keyid:D2:C4:****REMOVED FOR BREVITY****D:A8:6A:D4:E3
DirName:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
serial:00
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
32:4b:f3:b2:ca:3e:91:fc:12:c6:a1:07:8c:8e:77:a0:33:06:
14:5c:90:1e:18:f7:08:a6:3d:0a:19:f9:87:80:11:6e:69:e4:
96:17:30:ff:34:91:63:72:38:ee:cc:1c:01:a3:1d:94:28:a4:
****REMOVED FOR BREVITY****
10:43:a6:a5:9e:0a:d5:95:62:9a:0d:cf:88:82:c5:32:0c:e4:
2b:9f:45:e6:0d:9f:28:9c:b1:b9:2a:5a:57:ad:37:0f:af:1d:
7f:db:bd:9f
You'll need to sign with your private key, cert, and chain.
your-cert.pem is the certificate that GoDaddy issued you.
your-priv-key.pem is the private key you generated on your keychain or on the command line to create the CSR.
TheCertChain.pem is GoDaddy's certificate chain, you can find that on their website
FYI here's example code on how I'm signing a .mobileconfig in Ruby https://github.com/AppBlade/TestHub/blob/master/app/controllers/devices_controller.rb#L31
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