How do I generate an OpenSSL certificate with a "header"? - ssl

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).

Related

why does fabric-ca start as self-signed certificate?

Here is how I understand the flow.
version: '2'
services:
shop_ca:
image: hyperledger/fabric-ca
environment:
- FABRIC_CA_HOME=/etc/hyperledger/fabric-ca-server
- FABRIC_CA_SERVER_CA_NAME=shop_ca
- FABRIC_CA_SERVER_CA_CERTFILE=/etc/hyperledger/fabric-ca-server-config/ca-cert.pem
- FABRIC_CA_SERVER_CA_KEYFILE=/etc/hyperledger/fabric-ca-server-config/ca-key.pem
ports:
- "7054:7054"
command: sh -c 'fabric-ca-server start -b admin3:admin3'
volumes:
- ./conf.yaml:/etc/hyperledger/fabric-ca-server/fabric-ca-server-config.yaml
container_name: shop_ca
I passed my certfile and keyfile as options.
When the fabric-ca-server starts, what it should do is create ca-cert and ca-key pem files in /etc/hyperledger/fabric-ca-server folder. then use the /etc/hyperledger/fabric-ca-server/fabric-ca-server-config.yaml config file to generate the final certificate(path must be /etc/hyperledger/fabric-ca-server-config/ca-cert.pem) that will be used to issue other certificates.
What I don't understand is this generated certificate /etc/hyperledger/fabric-ca-server-config/ca-cert.pem is self-signed. Question is why? I think what it does is makes csr request to /etc/hyperledger/fabric-ca-server/ca-cert.pem and this ca-cert.pem issues another ca-cert.pem. This question happened on my mind because when I use openssl and print the final generated ca-cert certificate, issuer and subject are both the same. I think issuer has to be /etc/hyperledger/fabric-ca-server/ca-cert.pem and subject must be /etc/hyperledger/fabric-ca-server-config/ca-cert.pem. but both issuer and subject are /etc/hyperledger/fabric-ca-server-config/ca-cert.pem. Why?
The top root certificate for any Certificate Authority is always self-signed (check out the Verisign cert at the bottom of this post) ... that's why you explicitly trust root certificates.
Fabric CA allows you to either specify an existing root key pair or if the specified files do not exist it generates them for you. (if the cert file exists but a matching private key cannot be found you'll get an error and fabric-ca-server will not start).
When fabric-ca-server generates its own self-signed keypair, it actually generates the private key in the msp/keystore folder but it will store the self-signed X509 cert in the file specified via FABRIC_CA_SERVER_CA_CERTFILE if specified else it will use the location in fabric-ca-server-config.yaml. Note that if you use the FABRIC_CA_SERVER_CA_CERTFILE override, the value is not updated in the config file (perhaps this is causing some confusion).
Verisign Primary
Garis-MBP:tmp gsingh$ openssl x509 -noout -text -in verisign.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
18:da:d1:9e:26:7d:e8:bb:4a:21:58:cd:cc:6b:3b:4a
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
Validity
Not Before: Nov 8 00:00:00 2006 GMT
Not After : Jul 16 23:59:59 2036 GMT
Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:af:24:08:08:29:7a:35:9e:60:0c:aa:e7:4b:3b:
4e:dc:7c:bc:3c:45:1c:bb:2b:e0:fe:29:02:f9:57:
08:a3:64:85:15:27:f5:f1:ad:c8:31:89:5d:22:e8:
2a:aa:a6:42:b3:8f:f8:b9:55:b7:b1:b7:4b:b3:fe:
8f:7e:07:57:ec:ef:43:db:66:62:15:61:cf:60:0d:
a4:d8:de:f8:e0:c3:62:08:3d:54:13:eb:49:ca:59:
54:85:26:e5:2b:8f:1b:9f:eb:f5:a1:91:c2:33:49:
d8:43:63:6a:52:4b:d2:8f:e8:70:51:4d:d1:89:69:
7b:c7:70:f6:b3:dc:12:74:db:7b:5d:4b:56:d3:96:
bf:15:77:a1:b0:f4:a2:25:f2:af:1c:92:67:18:e5:
f4:06:04:ef:90:b9:e4:00:e4:dd:3a:b5:19:ff:02:
ba:f4:3c:ee:e0:8b:eb:37:8b:ec:f4:d7:ac:f2:f6:
f0:3d:af:dd:75:91:33:19:1d:1c:40:cb:74:24:19:
21:93:d9:14:fe:ac:2a:52:c7:8f:d5:04:49:e4:8d:
63:47:88:3c:69:83:cb:fe:47:bd:2b:7e:4f:c5:95:
ae:0e:9d:d4:d1:43:c0:67:73:e3:14:08:7e:e5:3f:
9f:73:b8:33:0a:cf:5d:3f:34:87:96:8a:ee:53:e8:
25:15
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
1.3.6.1.5.5.7.1.12:
0_.].[0Y0W0U..image/gif0!0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
X509v3 Subject Key Identifier:
7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33
Signature Algorithm: sha1WithRSAEncryption
93:24:4a:30:5f:62:cf:d8:1a:98:2f:3d:ea:dc:99:2d:bd:77:
f6:a5:79:22:38:ec:c4:a7:a0:78:12:ad:62:0e:45:70:64:c5:
e7:97:66:2d:98:09:7e:5f:af:d6:cc:28:65:f2:01:aa:08:1a:
47:de:f9:f9:7c:92:5a:08:69:20:0d:d9:3e:6d:6e:3c:0d:6e:
d8:e6:06:91:40:18:b9:f8:c1:ed:df:db:41:aa:e0:96:20:c9:
cd:64:15:38:81:c9:94:ee:a2:84:29:0b:13:6f:8e:db:0c:dd:
25:02:db:a4:8b:19:44:d2:41:7a:05:69:4a:58:4f:60:ca:7e:
82:6a:0b:02:aa:25:17:39:b5:db:7f:e7:84:65:2a:95:8a:bd:
86:de:5e:81:16:83:2d:10:cc:de:fd:a8:82:2a:6d:28:1f:0d:
0b:c4:e5:e7:1a:26:19:e1:f4:11:6f:10:b5:95:fc:e7:42:05:
32:db:ce:9d:51:5e:28:b6:9e:85:d3:5b:ef:a5:7d:45:40:72:
8e:b7:0e:6b:0e:06:fb:33:35:48:71:b8:9d:27:8b:c4:65:5f:
0d:86:76:9c:44:7a:f6:95:5c:f6:5d:32:08:33:a4:54:b6:18:
3f:68:5c:f2:42:4a:85:38:54:83:5f:d1:e8:2c:f2:ac:11:d6:
a8:ed:63:6a

Does openssl refuse self signed certificates without basic constraints?

I have two extremely similar self signed certificates, generated via two different methods.
To test them I have:
Added an entry in my hosts file for local.mydomain.com
Set up an nginx server to listen on that domain on port 443 with the certificate under test plus associated private key (I then switch the cert and restart nginx to compare)
Connected to nginx with openssl s_client -connect local.mydomain.com -CAfile /path/to/the/ca/cert.pem
One certificate fails:
CONNECTED(00000003)
depth=0 CN = local.mydomain.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = local.mydomain.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=local.mydomain.com
i:/CN=local.mydomain.com
---
One certificate succeeds:
CONNECTED(00000003)
depth=0 CN = local.mydomain.com
verify return:1
---
Certificate chain
0 s:/CN = local.mydomain.com
i:/CN = local.mydomain.com
---
I compare the details of the certificates with openssl x509 -in /path/to/the/ca/cert.pem -text -noout
The failing cert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
47:dc:02:c7:11:fc:8e:96:45:22:aa:6b:23:79:32:ca
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=local.mydomain.com
Validity
Not Before: Nov 18 11:55:31 2016 GMT
Not After : Nov 18 12:15:31 2017 GMT
Subject: CN=local.mydomain.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<stuff>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:local.mydomain.com
X509v3 Subject Key Identifier:
6D:4F:AF:E4:60:23:72:E5:83:27:91:7D:1D:5F:E9:7C:D9:B6:00:2A
Signature Algorithm: sha256WithRSAEncryption
<stuff>
The working cert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
9b:6b:3d:a3:b9:a3:a4:b4
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=local.mydomain.com
Validity
Not Before: Nov 19 13:27:30 2016 GMT
Not After : Nov 19 13:27:30 2017 GMT
Subject: CN=local.mydomain.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<stuff>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
03:E7:DA:AA:2E:CC:23:ED:C5:07:3D:E1:33:86:F5:22:D4:76:EB:CB
X509v3 Authority Key Identifier:
keyid:03:E7:DA:AA:2E:CC:23:ED:C5:07:3D:E1:33:86:F5:22:D4:76:EB:CB
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
57<stuff>
Looking at this the most obvious difference is that the working cert has CA:TRUE under X509v3 Basic Constraints. However, from reading around the web I was under the impression that self signed certs weren't meant to be CAs, in particular this says they normally won't be:
https://security.stackexchange.com/questions/44340/basic-self-signed-certificate-questions
The answer there says that being self-signed there is no CA involved. But maybe openssl requires self signed certs to have that set anyway?
From my own experiments I can confirm what you see. My explanation of the behavior is that a self signed certificate is still a certificate which is signed by the issuer, even if the issuer's certificate is the certificate itself. But only CA certificates can be used to sign certificates, i.e. that's exactly the constraint CA:true allows. This means that a self-signed certificate needs also to be a CA certificate with the constraint CA:true.
RFC5280 says:
So, if your certificate does not have CA:TRUE flag, this certificate may not be used to verify the signature on any certificate, including itself. OpenSSL correctly follows the RFC.
It is incorrect to think that a certificate belongs to one of two types, either "CA certificate" or "end-entity certificate". A certificate with CA:TRUE can be used for authenticating the entity. This is exactly what you do when you authenticate with a self-signed certificate. It can also be a certificate with CA:TRUE, signed by someone else.

Certificate Hierarchy shows only intermediate CA and not the Root CA

I followed the link https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html to create root CA and intermediate CA. Intermediate CA was signed by root CA.
When I check the intermediate CA (below is the output), you can find the issuer and subject are different(I mean root CA signed the intermediate certificate)
openssl x509 -noout -text -in certs/intermediate.cert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4096 (0x1000)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=IN, ST=Karnataka, L=JP Nager, O=XXX, OU=xxx, CN=abc/emailAddress=abc#xyz.com
Validity
Not Before: Jul 14 09:05:19 2016 GMT
Not After : Jul 12 09:05:19 2026 GMT
Subject: C=IN, ST=Karnataka, O=XXX, OU=xxx, CN=Ipad Intermidiate Certificate
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (4096 bit)
Modulus (4096 bit):
00:c6:44:d6:78:0d:f3:bc:69:8d:31:ce:00:01:8d:
d4:1b:ee:de:96:16:13:00:1e:f6:0e:7b:00:35:f2:
57:48:fc:fb:0c:38:9e:0e:d2:67:d0:b9:82:3d:28:
29:94:0a:95:a2:e2:5e:88:e7:77:cf:23:a3:2d:8a:
46:fa:d9:a7:c5:41:fc:b9:73:65:03:c1:98:8b:c3:
0a:e8:dc:4b:c5:cb:2f:5b:97:7a:46:9d:85:74:ae:
0c:c1:15:7d:58:c5:ea:7f:29:17:aa:e9:34:e9:f4:
9e:50:bb:ce:f3:59:26:aa:63:cc:f7:d4:03:0b:20:
83:10:a6:dc:d8:e0:6b:3b:ae:dd:14:20:ec:6a:93:
5e:83:11:cd:4b:3d:e0:08:a5:fb:b0:27:e3:2e:86:
45:1e:1c:d6:19:bd:8b:5d:fa:37:18:ad:fd:e2:ce:
b0:39:8a:5c:5a:d0:1d:46:8b:74:22:35:c0:9f:e7:
01:c7:0b:50:4f:ab:e2:01:90:3e:c5:d8:15:48:aa:
fe:4c:96:5e:fb:3f:3a:69:4c:d9:22:2a:5e:4e:39:
cc:75:0a:14:44:39:e6:5d:1b:f2:97:fc:a5:b1:c0:
ac:a5:21:49:56:ad:55:e4:08:54:af:17:14:47:f1:
47:03:4d:ac:c4:02:ae:5f:e8:d6:9c:fe:92:36:e3:
cd:30:65:60:56:c8:6e:0c:5a:df:08:b9:63:2e:4a:
d9:c3:af:20:32:81:7b:fa:0a:d6:0d:0c:5c:a0:36:
9c:fd:0d:d3:64:29:f5:e5:2b:16:86:65:06:7c:fc:
db:ed:e2:2b:02:5a:ae:53:63:30:48:59:6b:1d:3b:
5e:68:6e:2b:90:92:df:73:d9:10:1a:73:d0:da:e3:
4e:49:61:ea:ca:d9:b8:2d:4e:c5:26:e6:38:02:84:
fb:80:8b:97:55:d1:c2:2d:30:29:0c:25:cb:a4:6b:
d3:8d:c5:ec:40:76:5e:e5:8e:ed:4b:86:cb:c7:9b:
d1:3a:89:f3:97:ff:e9:8f:a7:6b:8d:d2:ca:00:cd:
f0:a7:3d:74:3b:6d:db:6c:d1:2c:f5:89:24:e8:6d:
7d:fe:f6:56:8e:62:8b:02:a4:5e:27:20:50:18:99:
c6:4a:38:70:8b:0a:bb:aa:16:b5:4d:54:29:29:46:
44:dd:4d:53:cd:82:8f:97:8b:a8:6e:17:33:6f:15:
16:08:31:e2:d7:bc:7e:46:a9:58:a9:2e:26:14:fb:
7d:38:30:10:9e:5d:2c:8e:6d:bf:f5:03:ed:bf:37:
b6:0c:9d:35:83:84:76:11:16:e2:14:f2:47:d5:7e:
1b:a2:da:74:ff:e1:e0:b2:07:f5:9d:4c:08:fa:c1:
5c:8f:1d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
D5:58:FE:D4:78:8A:93:77:28:65:04:D6:41:DB:A1:B0:FC:3E:37:F2
X509v3 Authority Key Identifier:
keyid:91:8E:47:44:08:F0:30:70:3A:9F:46:4C:C5:C9:D6:0C:17:D3:26:5D
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
Signature Algorithm: sha256WithRSAEncryption
90:80:df:ee:2d:37:33:ea:02:fc:95:dc:e5:04:e9:c2:75:4c:
85:39:a1:ee:86:94:13:6d:94:75:4d:35:be:2a:45:d6:50:7c:
e9:ec:49:51:80:6c:c2:3e:5d:ea:e5:fb:c2:d5:1a:c4:ad:be:
58:24:8a:c0:9f:8a:d3:df:5c:02:94:bb:e5:c0:cf:8c:76:7b:
9c:24:b2:af:37:fe:a2:a8:e3:6c:9b:bc:7b:2f:88:f0:99:1e:
3e:b7:40:76:c4:64:41:b8:70:67:09:ce:51:f2:16:b8:af:23:
Output of root ca certificate
openssl x509 -noout -text -in ca/certs/ca.cert.pem
Certificate:
Data:
Version:3 (0x2)
Serial Number:d1:4f:18:94:21:32:f1:c2
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=IN, ST=Karnataka, L=JP Nager, O=XXX, OU=xxx, CN=abc/emailAddress=abc#xyz.com
Validity
Not Before: Jul 14 07:07:30 2016 GMT
Not After : Jul 9 07:07:30 2036 GMT
Subject: C=IN, ST=Karnataka, L=JP Nager, O=XXX, OU=xxx, CN=abc/emailAddress=abc#xyz.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (4096 bit)
Modulus (4096 bit):
00:d4:f5:ac:3b:8f:85:d6:2b:e9:fc:d8:5c:7b:99:
85:70:2d:96:c3:fc:5c:25:79:07:a0:62:f6:2e:aa:
8a:5f:62:18:2c:3d:c1:18:9c:8d:46:d1:c1:da:7f:
7a:92:02:bc:31:86:d6:e2:19:f3:b1:6f:39:73:1d:
48:df:3a:a4:a3:8e:3a:b2:1a:46:50:6e:e5:af:b3:
a2:c2:eb:c7:73:70:2b:06:02:e8:2b:65:72:76:90:
1e:22:54:42:07:c6:2a:d5:4e:aa:4d:f8:29:b6:88:
e7:66:c8:e2:06:30:c1:05:4a:a1:5a:ec:90:d0:e2:
1a:15:69:d7:18:89:9a:d1:21:43:62:46:00:68:fd:
cd:bb:21:be:1b:4d:3e:7c:14:8b:b1:10:e5:c4:f8:
82:13:a8:b8:be:d8:99:ae:14:d8:46:c6:cb:e5:1a:
77:e7:a5:e4:b4:0f:64:14:72:91:d3:b0:33:98:26:
d4:22:ac:84:f0:57:c7:b6:ff:f2:18:14:e9:a3:d3:
ce:46:ac:ee:a9:3b:a3:a8:75:c6:62:90:29:3f:fc:
91:e8:e9:d4:86:2a:50:53:fd:ff:44:5e:32:4a:40:
67:84:64:b5:c4:dd:51:74:0c:d6:93:2d:f9:c3:34:
66:4c:62:b4:cf:5d:ee:d7:2a:ce:22:15:90:56:ac:
e0:95:1e:81:50:31:51:8c:70:26:ae:34:55:eb:e0:
58:14:8a:91:b5:79:aa:b5:51:3a:14:99:40:8d:68:
5f:ab:63:7d:bb:9a:c7:ae:66:64:3c:b0:2b:36:90:
43:b7:7c:d8:42:a2:33:95:6f:c4:cf:7d:1c:7c:87:
af:d6:4d:50:73:91:ce:90:69:d4:51:3d:f3:d3:07:
92:fa:b0:d7:b0:e6:59:db:b8:de:7f:6b:7f:4b:4c:
71:69:49:a5:83:72:67:95:d6:2b:e5:d9:d3:e9:12:
43:c2:68:1b:37:85:3f:a7:2e:3e:d0:78:06:29:85:
31:f8:1e:2e:43:d5:ae:55:3c:80:38:1c:e0:84:61:
37:84:b4:8e:e8:30:48:da:2a:95:2b:0c:6c:2c:15:
ef:96:af:12:f9:4c:c2:96:f8:86:c4:d5:db:cc:6b:
4c:92:ca:39:ed:b6:72:e5:d2:78:24:38:c1:e1:b6:
bd:f0:7c:50:e6:c8:ec:ca:f4:ae:a6:52:0a:57:3b:
87:f8:1c:c1:f1:22:28:5a:5b:f1:c9:3b:68:70:32:
6c:e3:96:60:eb:70:64:79:38:d9:93:42:d9:38:2c:
be:42:02:23:6d:09:ab:56:6b:fd:5c:c8:dc:1e:de:
6f:fe:a7:69:2e:65:61:1d:54:6b:d5:6b:93:ac:89:
a3:20:47
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
91:8E:47:44:08:F0:30:70:3A:9F:46:4C:C5:C9:D6:0C:17:D3:26:5D
X509v3 Authority Key Identifier:
keyid:91:8E:47:44:08:F0:30:70:3A:9F:46:4C:C5:C9:D6:0C:17:D3:26:5D
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
Signature Algorithm: sha256WithRSAEncryption
20:b7:52:b6:0d:12:34:26:fe:b6:f3:20:7e:83:71:2c:a9:48:
4e:08:6f:87:a7:9d:89:38:a7:c1:f2:dd:f9:a3:54:87:24:09:
99:28:d8:5e:8a:a5:65:3d:1c:ee:82:68:cb:6c:5d:9d:51:3a:
06:ab:ea:b2:10:7c:6e:d8:f7:a5:1e:ed:19:18:2b:d0:36:93:
f5:e6:c1:00:b5:9c:b5:61:c9:13:52:6b:59:f7:da:ae:9a:c4:
ad:cb:6b:f4:07:22:45:69:c4:9c:a7:50:b7:47:4b:bc:52:73:
e9:7a:aa:8c:6c:ec:0f:ba:86:93:48:50:d3:32:4e:dc:df:96:
20:41:e0:47:c0:d4:cb:c2:54:9e:21:54:36:77:df:69:e3:0d:
3e:19:ee:a3:a4:d7:3d:d0:bb:63:a6:80:27:57:54:84:20:17:
79:3e:c8:19:4b:7e:1d:d4:cc:75:a2:9e:48:a6:8f:23:c2:a5:
a0:30:7d:a6:83:e6:14:9a:0e:91:58:de:71:46:0b:d2:ee:27:
d7:61:31:f9:2e:f7:c2:fa:19:76:21:a0:6a:46:b0:34:1f:25:
f0:ef:7f:b7:12:11:46:ec:28:de:b8:a2:f5:4e:ab:6d:a6:eb:
2e:77:f5:74:e9:b0:c0:58:99:c9:c8:97:8a:92:1a:95:d1:21:
9a:42:b5:df:f5:df:34:82:a8:2d:9d:41:4b:56:73:4f:84:dd:
fa:0d:b7:6a:9a:0f:e7:09:7a:0d:b7:d8:6e:97:a5:0e:bc:49:
6a:aa:7e:87:05:f2:73:00:5a:7b:ec:f5:2a:0f:04:c8:72:40:
24:d1:29:1d:d6:a9:ab:2c:09:4c:3c:9d:7e:a3:3e:c5:49:04:
71:8c:88:10:c7:dd:f7:9b:05:6f:e5:bf:e1:de:d1:b4:59:a8:
4c:ef:37:30:d2:71:fd:a6:7c:d6:88:6e:bc:73:ed:99:7e:0e:
ff:04:4b:52:e9:30:44:36:db:7e:0d:31:86:13:95:64:14:b4:
44:95:0a:c4:6f:13:06:c8:07:a4:13:fe:f8:eb:5b:27:44:b0:
26:71:97:b5:48:ba:73:1a:f4:53:65:bd:bd:cd:d5:5f:9b:64:
a8:ab:71:d0:9d:ad:a8:a0:fb:8f:a7:37:1d:f7:62:3e:a0:69:
7c:25:4a:fb:5d:3f:81:9f:7b:2a:40:0b:35:90:5b:47:8d:55:
36:c7:0f:8c:cb:53:62:f1:ae:5f:13:74:52:eb:dc:21:01:8f:
c6:6e:35:25:ae:2a:d1:60:9e:98:51:ca:2e:b8:0c:3c:00:db:
7c:a2:82:b2:97:71:99:78:77:84:8d:91:8e:de:5b:80:61:99:
70:c5:56:3f:12:e8:ff:e0**
Now, when I access a webserver which has the certificate signed by the intermediate CA ,the browser throws error saying the certificate is not valid the reason being in the Certificate Hierarchy root CA information is not there.
Please let me know if I am missing anything.

Extracting certificate parts to sign file with OpenSSL

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

openssl x509 - what is trusted and rejected uses of SSL certificate?

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.