google/stenographer

Stenoread certificate error

dcode opened this issue · 6 comments

dcode commented

When using stenocurl on the CentOS 7.2, I get an error indicating that the certificate usage type is incorrect.

vagrant@simplerockbuild ~]$ stenocurl /debug/
curl: (60) Certificate type not approved for application.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

I've used the -k as a work around, but this is obviously less than ideal. I'm running this in Vagrant using SimpleRock [1] (of which I'm an author).

I checked the certificates and they appear to be correct for the roles I would expect. The server cert has TLS web server auth + certificate sign and the client cert has TLS client auth. I'm wondering if there was a change in OpenSSL that it causing this to occur. I haven't been able to trace it down yet. I'm happy to do the leg work if I can just figure out why this is occurring.

In the meantime, I'm using the -k curl option, which I'd rather not do.

thanks!

[vagrant@simplerockbuild ~]$ openssl x509 -in /etc/stenographer/certs/server_cert.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6c:c1:6c:34:e9:18:98:17:62:32:be:50:f8:c0:24:dd
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=Stenographer, CN=127.0.0.1
        Validity
            Not Before: Dec 24 20:19:05 2015 GMT
            Not After : Dec 23 20:19:05 2016 GMT
        Subject: O=Stenographer, CN=127.0.0.1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ae:df:27:70:f8:fe:dc:e8:33:f9:22:84:08:1b:
                    a3:32:46:16:57:01:3f:a9:96:66:aa:7b:8c:5d:5b:
                    46:6d:c9:73:a3:f8:38:2d:92:45:90:b8:a0:96:c7:
                    ba:5b:bd:d2:c6:a2:1d:63:08:56:9f:19:e4:12:4f:
                    1e:c4:84:69:e9:fa:35:4a:0b:32:39:5c:3c:5e:43:
                    2b:dd:9c:79:dc:aa:d6:b2:b6:75:c0:00:71:d1:6d:
                    52:18:11:32:19:24:b0:19:9b:5c:15:9c:54:94:1d:
                    e9:e0:89:25:59:a8:69:0e:bc:b9:d8:97:31:0a:5d:
                    03:c8:a4:cb:21:18:d7:04:7d:de:51:40:ac:28:55:
                    4e:c5:1b:43:9a:8f:44:84:6b:f8:02:22:1c:6b:60:
                    8a:a5:25:1e:98:55:e2:37:ea:1d:2a:b2:bd:15:1a:
                    49:5b:bb:ce:9a:3e:92:09:d6:fc:b3:f8:1a:cc:f5:
                    16:e3:18:8d:84:5d:7f:e9:a0:28:02:39:62:f6:71:
                    1f:9d:62:bc:53:e1:5c:39:1a:41:ff:37:d5:45:44:
                    04:21:0c:66:33:c9:76:87:71:d9:50:50:ee:d6:27:
                    0d:8f:90:c8:5e:8b:7c:61:05:92:d6:97:0d:34:af:
                    5e:a6:72:78:f9:f2:ec:f8:89:3a:59:ca:0b:77:08:
                    02:3d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Alternative Name:
                DNS:localhost, IP Address:127.0.0.1
    Signature Algorithm: sha256WithRSAEncryption
         48:7a:43:4a:1b:b6:47:ca:47:88:91:48:51:1e:3b:e6:4b:f2:
         20:80:93:3d:a0:84:73:0a:2f:5e:97:0f:dd:79:7e:ff:89:d9:
         09:f4:2f:cd:65:f1:19:62:35:df:b8:ce:c4:28:14:b7:9a:a7:
         73:07:d1:71:db:69:1b:b7:0f:e1:95:f4:cf:97:00:7a:8a:65:
         3e:dc:3d:c0:35:22:10:8c:88:58:f0:0d:eb:a8:f7:10:4f:48:
         d7:13:9b:42:7b:a6:b0:e5:1c:aa:fd:b3:a3:91:9d:cf:63:fb:
         1a:06:74:6e:91:0b:01:bb:73:8f:49:b5:85:59:a5:a1:f6:1d:
         87:75:11:49:c0:75:f0:40:05:31:9c:a4:56:58:9f:4a:b1:8a:
         5d:60:c3:0d:1f:00:c6:05:17:18:c9:0c:b7:dd:fc:34:7f:79:
         d6:65:15:d4:a6:cf:38:97:dd:5f:a4:45:03:dd:ac:6a:9d:5a:
         9b:eb:d3:e0:9c:7c:9b:7d:ac:d4:15:c4:d5:bb:e3:df:73:c3:
         66:cd:8d:fe:78:0a:88:e6:b0:b5:52:f5:da:af:e8:07:d9:0d:
         d0:fa:2b:b1:dc:99:2e:2d:66:e0:ba:70:b7:d8:b4:1f:02:9a:
         6c:c6:a9:d0:21:c5:f1:74:62:9b:9c:11:f9:60:16:d1:11:06:
         4d:78:d5:68
[vagrant@simplerockbuild ~]$ openssl x509 -in /etc/stenographer/certs/client_cert.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            2f:ef:54:2a:ee:96:83:23:eb:12:d0:ec:80:c4:b5:cd
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=Stenographer, CN=127.0.0.1
        Validity
            Not Before: Dec 24 20:19:04 2015 GMT
            Not After : Dec 23 20:19:04 2016 GMT
        Subject: O=Stenographer, CN=127.0.0.1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c8:54:35:c0:ad:f5:48:b9:a1:43:f4:17:4b:25:
                    b2:ac:0b:a2:07:39:51:66:97:c7:27:5f:bd:90:e3:
                    cd:ce:b8:61:9b:f4:6f:bb:26:47:7e:62:d8:25:7d:
                    01:91:6d:37:79:42:70:b7:0e:1a:a7:a6:e7:5a:33:
                    ff:70:38:e4:f0:f9:29:01:88:bb:15:c2:ec:9a:65:
                    8d:fb:7b:12:72:8b:e8:f4:9e:7c:c9:09:4d:ca:81:
                    e4:5d:63:76:20:df:dd:ef:eb:5c:43:e7:bb:eb:b1:
                    c4:10:47:af:7a:e1:5e:de:0f:e1:a5:35:34:67:57:
                    40:fa:46:32:62:57:29:66:c5:3b:59:9b:ce:19:6e:
                    2a:3e:b9:2e:79:65:21:7c:4e:d7:7f:8e:31:d5:24:
                    1d:62:a6:45:fc:aa:1d:1a:80:a4:d9:7e:07:79:a4:
                    3a:de:35:0d:b7:2a:1b:60:27:2c:0f:c1:b0:a6:49:
                    8f:fc:79:b2:6a:67:9e:0a:a5:4d:9c:19:7a:68:4a:
                    cc:6c:b6:8d:94:6d:f0:e0:d5:a1:16:ca:b5:65:ba:
                    38:f0:37:6f:83:cb:87:d6:c1:14:1b:4c:3a:a1:0b:
                    30:11:b1:04:b0:69:f7:f8:45:a3:b6:36:17:47:bb:
                    dc:41:d2:6f:9f:00:b8:70:40:54:dc:06:a6:e1:9d:
                    68:1f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Alternative Name:
                DNS:localhost, IP Address:127.0.0.1
    Signature Algorithm: sha256WithRSAEncryption
         43:d5:e2:95:9f:5f:98:d7:34:23:3f:f9:ba:6d:6c:76:65:69:
         a0:6c:92:9b:7c:83:0d:86:9e:60:af:8b:7e:73:fc:4d:2b:b5:
         c8:7b:2f:f0:37:e5:61:86:99:b3:38:3d:6e:c6:19:1f:d4:dd:
         02:20:ff:1f:bd:46:11:ac:07:19:23:3b:ac:96:53:10:de:5b:
         7e:34:f2:69:59:0c:06:93:f4:3b:7f:93:ef:2b:77:8a:7a:d4:
         fe:d3:de:5e:2a:31:cc:fd:cf:dd:ea:4c:7c:60:b8:99:e9:01:
         b7:d2:05:b6:e4:d8:ad:71:c2:1e:ae:59:2c:a4:82:f8:0d:a1:
         fd:0f:75:63:9c:53:f5:f2:18:5a:69:0f:e2:42:6b:8e:f9:65:
         90:b0:0d:71:69:ce:e6:f7:48:de:20:1f:a5:89:fc:21:16:81:
         4f:10:4c:51:90:e6:00:35:4f:23:c6:df:7c:83:69:7c:1f:86:
         83:ad:92:de:c9:f1:05:df:ab:6a:8d:0e:9b:1a:3b:40:10:c7:
         8e:ff:86:48:d2:37:18:3a:2e:2a:b5:ec:3a:3c:d1:53:63:43:
         59:7a:f7:3e:6e:e6:8a:b3:f7:b6:d6:d3:47:99:f9:38:d0:d9:
         fe:12:e4:0d:ad:62:47:53:5a:cb:a2:fd:a8:08:f5:b4:c7:a3:
         ad:4c:63:eb

References:
[1] SimpleRock, http://rocknsm.io/

gconnell commented

That's QUITE strange... nothing's changed in the Steno cert generation code
recently. Here's a thought: are you maybe talking to IPv6 localhost (::1)
instead of IPv4 localhost (127.*)? Maybe we need to add IPv6 localhost to
the certs.

On Thu, Dec 24, 2015 at 1:42 PM, dcode notifications@github.com wrote:

When using stenocurl on the CentOS 7.2, I get an error indicating that
the certificate usage type is incorrect.

vagrant@simplerockbuild ~]$ stenocurl /debug/
curl: (60) Certificate type not approved for application.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

I've used the -k as a work around, but this is obviously less than ideal.
I'm running this in Vagrant using SimpleRock 1
http://of%20which%20I'm%20an%20author.

I checked the certificates and they appear to be correct for the roles I
would expect. The server cert has TLS web server auth + certificate sign
and the client cert has TLS client auth. I'm wondering if there was a
change in OpenSSL that it causing this to occur. I haven't been able to
trace it down yet. I'm happy to do the leg work if I can just figure out
why this is occurring.

In the meantime, I'm using the -k curl option, which I'd rather not do.

thanks!

[vagrant@simplerockbuild ~]$ openssl x509 -in /etc/stenographer/certs/server_cert.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
6c:c1:6c:34:e9:18:98:17:62:32:be:50:f8:c0:24:dd
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=Stenographer, CN=127.0.0.1
Validity
Not Before: Dec 24 20:19:05 2015 GMT
Not After : Dec 23 20:19:05 2016 GMT
Subject: O=Stenographer, CN=127.0.0.1
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ae:df:27:70:f8:fe:dc:e8:33:f9:22:84:08:1b:
a3:32:46:16:57:01:3f:a9:96:66:aa:7b:8c:5d:5b:
46:6d:c9:73:a3:f8:38:2d:92:45:90:b8:a0:96:c7:
ba:5b:bd:d2:c6:a2:1d:63:08:56:9f:19:e4:12:4f:
1e:c4:84:69:e9:fa:35:4a:0b:32:39:5c:3c:5e:43:
2b:dd:9c:79:dc:aa:d6:b2:b6:75:c0:00:71:d1:6d:
52:18:11:32:19:24:b0:19:9b:5c:15:9c:54:94:1d:
e9:e0:89:25:59:a8:69:0e:bc:b9:d8:97:31:0a:5d:
03:c8:a4:cb:21:18:d7:04:7d:de:51:40:ac:28:55:
4e:c5:1b:43:9a:8f:44:84:6b:f8:02:22:1c:6b:60:
8a:a5:25:1e:98:55:e2:37:ea:1d:2a:b2:bd:15:1a:
49:5b:bb:ce:9a:3e:92:09:d6:fc:b3:f8:1a:cc:f5:
16:e3:18:8d:84:5d:7f:e9:a0:28:02:39:62:f6:71:
1f:9d:62:bc:53:e1:5c:39:1a:41:ff:37:d5:45:44:
04:21:0c:66:33:c9:76:87:71:d9:50:50:ee:d6:27:
0d:8f:90:c8:5e:8b:7c:61:05:92:d6:97:0d:34:af:
5e:a6:72:78:f9:f2:ec:f8:89:3a:59:ca:0b:77:08:
02:3d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Alternative Name:
DNS:localhost, IP Address:127.0.0.1
Signature Algorithm: sha256WithRSAEncryption
48:7a:43:4a:1b:b6:47:ca:47:88:91:48:51:1e:3b:e6:4b:f2:
20:80:93:3d:a0:84:73:0a:2f:5e:97:0f:dd:79:7e:ff:89:d9:
09:f4:2f:cd:65:f1:19:62:35:df:b8:ce:c4:28:14:b7:9a:a7:
73:07:d1:71:db:69:1b:b7:0f:e1:95:f4:cf:97:00:7a:8a:65:
3e:dc:3d:c0:35:22:10:8c:88:58:f0:0d:eb:a8:f7:10:4f:48:
d7:13:9b:42:7b:a6:b0:e5:1c:aa:fd:b3:a3:91:9d:cf:63:fb:
1a:06:74:6e:91:0b:01:bb:73:8f:49:b5:85:59:a5:a1:f6:1d:
87:75:11:49:c0:75:f0:40:05:31:9c:a4:56:58:9f:4a:b1:8a:
5d:60:c3:0d:1f:00:c6:05:17:18:c9:0c:b7:dd:fc:34:7f:79:
d6:65:15:d4:a6:cf:38:97:dd:5f:a4:45:03:dd:ac:6a:9d:5a:
9b:eb:d3:e0:9c:7c:9b:7d:ac:d4:15:c4:d5:bb:e3:df:73:c3:
66:cd:8d:fe:78:0a:88:e6:b0:b5:52:f5:da:af:e8:07:d9:0d:
d0:fa:2b:b1:dc:99:2e:2d:66:e0:ba:70:b7:d8:b4:1f:02:9a:
6c:c6:a9:d0:21:c5:f1:74:62:9b:9c:11:f9:60:16:d1:11:06:
4d:78:d5:68
[vagrant@simplerockbuild ~]$ openssl x509 -in /etc/stenographer/certs/client_cert.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
2f:ef:54:2a:ee:96:83:23:eb:12:d0:ec:80:c4:b5:cd
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=Stenographer, CN=127.0.0.1
Validity
Not Before: Dec 24 20:19:04 2015 GMT
Not After : Dec 23 20:19:04 2016 GMT
Subject: O=Stenographer, CN=127.0.0.1
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c8:54:35:c0:ad:f5:48:b9:a1:43:f4:17:4b:25:
b2:ac:0b:a2:07:39:51:66:97:c7:27:5f:bd:90:e3:
cd:ce:b8:61:9b:f4:6f:bb:26:47:7e:62:d8:25:7d:
01:91:6d:37:79:42:70:b7:0e:1a:a7:a6:e7:5a:33:
ff:70:38:e4:f0:f9:29:01:88:bb:15:c2:ec:9a:65:
8d:fb:7b:12:72:8b:e8:f4:9e:7c:c9:09:4d:ca:81:
e4:5d:63:76:20:df:dd:ef:eb:5c:43:e7:bb:eb:b1:
c4:10:47:af:7a:e1:5e:de:0f:e1:a5:35:34:67:57:
40:fa:46:32:62:57:29:66:c5:3b:59:9b:ce:19:6e:
2a:3e:b9:2e:79:65:21:7c:4e:d7:7f:8e:31:d5:24:
1d:62:a6:45:fc:aa:1d:1a:80:a4:d9:7e:07:79:a4:
3a:de:35:0d:b7:2a:1b:60:27:2c:0f:c1:b0:a6:49:
8f:fc:79:b2:6a:67:9e:0a:a5:4d:9c:19:7a:68:4a:
cc:6c:b6:8d:94:6d:f0:e0:d5:a1:16:ca:b5:65:ba:
38:f0:37:6f:83:cb:87:d6:c1:14:1b:4c:3a:a1:0b:
30:11:b1:04:b0:69:f7:f8:45:a3:b6:36:17:47:bb:
dc:41:d2:6f:9f:00:b8:70:40:54:dc:06:a6:e1:9d:
68:1f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Alternative Name:
DNS:localhost, IP Address:127.0.0.1
Signature Algorithm: sha256WithRSAEncryption
43:d5:e2:95:9f:5f:98:d7:34:23:3f:f9:ba:6d:6c:76:65:69:
a0:6c:92:9b:7c:83:0d:86:9e:60:af:8b:7e:73:fc:4d:2b:b5:
c8:7b:2f:f0:37:e5:61:86:99:b3:38:3d:6e:c6:19:1f:d4:dd:
02:20:ff:1f:bd:46:11:ac:07:19:23:3b:ac:96:53:10:de:5b:
7e:34:f2:69:59:0c:06:93:f4:3b:7f:93:ef:2b:77:8a:7a:d4:
fe:d3:de:5e:2a:31:cc:fd:cf:dd:ea:4c:7c:60:b8:99:e9:01:
b7:d2:05:b6:e4:d8:ad:71:c2:1e:ae:59:2c:a4:82:f8:0d:a1:
fd:0f:75:63:9c:53:f5:f2:18:5a:69:0f:e2:42:6b:8e:f9:65:
90:b0:0d:71:69:ce:e6:f7:48:de:20:1f:a5:89:fc:21:16:81:
4f:10:4c:51:90:e6:00:35:4f:23:c6:df:7c:83:69:7c:1f:86:
83:ad:92:de:c9:f1:05:df:ab:6a:8d:0e:9b:1a:3b:40:10:c7:
8e:ff:86:48:d2:37:18:3a:2e:2a:b5:ec:3a:3c:d1:53:63:43:
59:7a:f7:3e:6e:e6:8a:b3:f7:b6:d6:d3:47:99:f9:38:d0:d9:
fe:12:e4:0d:ad:62:47:53:5a:cb:a2:fd:a8:08:f5:b4:c7:a3:
ad:4c:63:eb

[1] http://rocknsm.io/

—
Reply to this email directly or view it on GitHub
#124.

gconnell commented

To test this out, maybe tcpdump on the 'lo' interface and see if you're
seeing v4 or v6 packets.

On Mon, Jan 4, 2016 at 9:30 AM, Graeme Connell gconnell@google.com wrote:

That's QUITE strange... nothing's changed in the Steno cert generation
code recently. Here's a thought: are you maybe talking to IPv6 localhost
(::1) instead of IPv4 localhost (127.*)? Maybe we need to add IPv6
localhost to the certs.

On Thu, Dec 24, 2015 at 1:42 PM, dcode notifications@github.com wrote:

When using stenocurl on the CentOS 7.2, I get an error indicating that
the certificate usage type is incorrect.

vagrant@simplerockbuild ~]$ stenocurl /debug/
curl: (60) Certificate type not approved for application.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

I've used the -k as a work around, but this is obviously less than ideal.
I'm running this in Vagrant using SimpleRock 1
http://of%20which%20I'm%20an%20author.

I checked the certificates and they appear to be correct for the roles I
would expect. The server cert has TLS web server auth + certificate sign
and the client cert has TLS client auth. I'm wondering if there was a
change in OpenSSL that it causing this to occur. I haven't been able to
trace it down yet. I'm happy to do the leg work if I can just figure out
why this is occurring.

In the meantime, I'm using the -k curl option, which I'd rather not do.

thanks!

[vagrant@simplerockbuild ~]$ openssl x509 -in /etc/stenographer/certs/server_cert.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
6c:c1:6c:34:e9:18:98:17:62:32:be:50:f8:c0:24:dd
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=Stenographer, CN=127.0.0.1
Validity
Not Before: Dec 24 20:19:05 2015 GMT
Not After : Dec 23 20:19:05 2016 GMT
Subject: O=Stenographer, CN=127.0.0.1
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ae:df:27:70:f8:fe:dc:e8:33:f9:22:84:08:1b:
a3:32:46:16:57:01:3f:a9:96:66:aa:7b:8c:5d:5b:
46:6d:c9:73:a3:f8:38:2d:92:45:90:b8:a0:96:c7:
ba:5b:bd:d2:c6:a2:1d:63:08:56:9f:19:e4:12:4f:
1e:c4:84:69:e9:fa:35:4a:0b:32:39:5c:3c:5e:43:
2b:dd:9c:79:dc:aa:d6:b2:b6:75:c0:00:71:d1:6d:
52:18:11:32:19:24:b0:19:9b:5c:15:9c:54:94:1d:
e9:e0:89:25:59:a8:69:0e:bc:b9:d8:97:31:0a:5d:
03:c8:a4:cb:21:18:d7:04:7d:de:51:40:ac:28:55:
4e:c5:1b:43:9a:8f:44:84:6b:f8:02:22:1c:6b:60:
8a:a5:25:1e:98:55:e2:37:ea:1d:2a:b2:bd:15:1a:
49:5b:bb:ce:9a:3e:92:09:d6:fc:b3:f8:1a:cc:f5:
16:e3:18:8d:84:5d:7f:e9:a0:28:02:39:62:f6:71:
1f:9d:62:bc:53:e1:5c:39:1a:41:ff:37:d5:45:44:
04:21:0c:66:33:c9:76:87:71:d9:50:50:ee:d6:27:
0d:8f:90:c8:5e:8b:7c:61:05:92:d6:97:0d:34:af:
5e:a6:72:78:f9:f2:ec:f8:89:3a:59:ca:0b:77:08:
02:3d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Alternative Name:
DNS:localhost, IP Address:127.0.0.1
Signature Algorithm: sha256WithRSAEncryption
48:7a:43:4a:1b:b6:47:ca:47:88:91:48:51:1e:3b:e6:4b:f2:
20:80:93:3d:a0:84:73:0a:2f:5e:97:0f:dd:79:7e:ff:89:d9:
09:f4:2f:cd:65:f1:19:62:35:df:b8:ce:c4:28:14:b7:9a:a7:
73:07:d1:71:db:69:1b:b7:0f:e1:95:f4:cf:97:00:7a:8a:65:
3e:dc:3d:c0:35:22:10:8c:88:58:f0:0d:eb:a8:f7:10:4f:48:
d7:13:9b:42:7b:a6:b0:e5:1c:aa:fd:b3:a3:91:9d:cf:63:fb:
1a:06:74:6e:91:0b:01:bb:73:8f:49:b5:85:59:a5:a1:f6:1d:
87:75:11:49:c0:75:f0:40:05:31:9c:a4:56:58:9f:4a:b1:8a:
5d:60:c3:0d:1f:00:c6:05:17:18:c9:0c:b7:dd:fc:34:7f:79:
d6:65:15:d4:a6:cf:38:97:dd:5f:a4:45:03:dd:ac:6a:9d:5a:
9b:eb:d3:e0:9c:7c:9b:7d:ac:d4:15:c4:d5:bb:e3:df:73:c3:
66:cd:8d:fe:78:0a:88:e6:b0:b5:52:f5:da:af:e8:07:d9:0d:
d0:fa:2b:b1:dc:99:2e:2d:66:e0:ba:70:b7:d8:b4:1f:02:9a:
6c:c6:a9:d0:21:c5:f1:74:62:9b:9c:11:f9:60:16:d1:11:06:
4d:78:d5:68
[vagrant@simplerockbuild ~]$ openssl x509 -in /etc/stenographer/certs/client_cert.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
2f:ef:54:2a:ee:96:83:23:eb:12:d0:ec:80:c4:b5:cd
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=Stenographer, CN=127.0.0.1
Validity
Not Before: Dec 24 20:19:04 2015 GMT
Not After : Dec 23 20:19:04 2016 GMT
Subject: O=Stenographer, CN=127.0.0.1
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c8:54:35:c0:ad:f5:48:b9:a1:43:f4:17:4b:25:
b2:ac:0b:a2:07:39:51:66:97:c7:27:5f:bd:90:e3:
cd:ce:b8:61:9b:f4:6f:bb:26:47:7e:62:d8:25:7d:
01:91:6d:37:79:42:70:b7:0e:1a:a7:a6:e7:5a:33:
ff:70:38:e4:f0:f9:29:01:88:bb:15:c2:ec:9a:65:
8d:fb:7b:12:72:8b:e8:f4:9e:7c:c9:09:4d:ca:81:
e4:5d:63:76:20:df:dd:ef:eb:5c:43:e7:bb:eb:b1:
c4:10:47:af:7a:e1:5e:de:0f:e1:a5:35:34:67:57:
40:fa:46:32:62:57:29:66:c5:3b:59:9b:ce:19:6e:
2a:3e:b9:2e:79:65:21:7c:4e:d7:7f:8e:31:d5:24:
1d:62:a6:45:fc:aa:1d:1a:80:a4:d9:7e:07:79:a4:
3a:de:35:0d:b7:2a:1b:60:27:2c:0f:c1:b0:a6:49:
8f:fc:79:b2:6a:67:9e:0a:a5:4d:9c:19:7a:68:4a:
cc:6c:b6:8d:94:6d:f0:e0:d5:a1:16:ca:b5:65:ba:
38:f0:37:6f:83:cb:87:d6:c1:14:1b:4c:3a:a1:0b:
30:11:b1:04:b0:69:f7:f8:45:a3:b6:36:17:47:bb:
dc:41:d2:6f:9f:00:b8:70:40:54:dc:06:a6:e1:9d:
68:1f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Alternative Name:
DNS:localhost, IP Address:127.0.0.1
Signature Algorithm: sha256WithRSAEncryption
43:d5:e2:95:9f:5f:98:d7:34:23:3f:f9:ba:6d:6c:76:65:69:
a0:6c:92:9b:7c:83:0d:86:9e:60:af:8b:7e:73:fc:4d:2b:b5:
c8:7b:2f:f0:37:e5:61:86:99:b3:38:3d:6e:c6:19:1f:d4:dd:
02:20:ff:1f:bd:46:11:ac:07:19:23:3b:ac:96:53:10:de:5b:
7e:34:f2:69:59:0c:06:93:f4:3b:7f:93:ef:2b:77:8a:7a:d4:
fe:d3:de:5e:2a:31:cc:fd:cf:dd:ea:4c:7c:60:b8:99:e9:01:
b7:d2:05:b6:e4:d8:ad:71:c2:1e:ae:59:2c:a4:82:f8:0d:a1:
fd:0f:75:63:9c:53:f5:f2:18:5a:69:0f:e2:42:6b:8e:f9:65:
90:b0:0d:71:69:ce:e6:f7:48:de:20:1f:a5:89:fc:21:16:81:
4f:10:4c:51:90:e6:00:35:4f:23:c6:df:7c:83:69:7c:1f:86:
83:ad:92:de:c9:f1:05:df:ab:6a:8d:0e:9b:1a:3b:40:10:c7:
8e:ff:86:48:d2:37:18:3a:2e:2a:b5:ec:3a:3c:d1:53:63:43:
59:7a:f7:3e:6e:e6:8a:b3:f7:b6:d6:d3:47:99:f9:38:d0:d9:
fe:12:e4:0d:ad:62:47:53:5a:cb:a2:fd:a8:08:f5:b4:c7:a3:
ad:4c:63:eb

[1] http://rocknsm.io/

—
Reply to this email directly or view it on GitHub
#124.

dcode commented

@gconnell that is an astute observation. CentOS 7.x includes localhost for both IPv4 and IPv6 loopback. This has bit me in butt a couple times before.

I just checked, and that's not the case, however. When I test using openssl directly, it works (I get a connected socket and certificate validates):

openssl s_client -key /etc/stenographer/certs/client_key.pem -cert /etc/stenographer/certs/client_cert.pem -CAfile /etc/stenographer/certs/server_cert.pem -showcerts -connect 127.0.0.1:1234
CONNECTED(00000003)
depth=0 O = Stenographer, CN = 127.0.0.1
verify return:1
---
Certificate chain
 0 s:/O=Stenographer/CN=127.0.0.1
   i:/O=Stenographer/CN=127.0.0.1
-----BEGIN CERTIFICATE-----
///// TRIMMED FOR BREVITY //////
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Stenographer/CN=127.0.0.1
issuer=/O=Stenographer/CN=127.0.0.1
---
Acceptable client certificate CA names
/O=Stenographer/CN=127.0.0.1
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 2326 bytes and written 1504 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: 7200425460A3A9BFA96F2A97120918653741AFA7FA2E309CA1B1D07747551BD1
    Session-ID-ctx:
    Master-Key: 1189080494B3A5FBCB7A198D117F4787358B0E5C1B6DEBB9CE5D4485E09D72310165361BB0F2277F5963314A5CC4A565
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket:
////// TRIMMED FOR BREVITY  ///////

    Start Time: 1451930274
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

If I manually run it in curl, I get the following

[vagrant@simplerockbuild ~]$ curl -iv --cacert /etc/stenographer/certs/server_cert.pem --cert /etc/stenographer/certs/client_cert.pem --key /etc/stenographer/certs/client_key.pem https://localhost:1234/
* About to connect() to localhost port 1234 (#0)
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 1234 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/stenographer/certs/server_cert.pem
  CApath: none
* Server certificate:
*   subject: CN=127.0.0.1,O=Stenographer
*   start date: Jan 04 17:54:08 2016 GMT
*   expire date: Jan 03 17:54:08 2017 GMT
*   common name: 127.0.0.1
*   issuer: CN=127.0.0.1,O=Stenographer
* NSS error -8101 (SEC_ERROR_INADEQUATE_CERT_TYPE)
* Certificate type not approved for application.
* Closing connection 0
curl: (60) Certificate type not approved for application.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

I found an issue with Firefox that sounds related (link). The user suggests that the CA cert cannot have an extended usage. Not sure if that change occurred in curl. I'll dig in more there.

curl --version
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.19.1 Basic ECC zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz
gconnell commented

Ah, that definitely sounds like it could be related. Here's the cert
generation code:
https://github.com/google/stenographer/blob/master/certs/certs.go#L57 I'm
not too familiar with SSL, so I mostly just munged things until it worked.
Please keep digging! I may not have time to take a look today, but if you
haven't found a root cause in a day or two I might be able to dive in.

Thanks a ton for the investigation you've done so far!

--Graeme

On Mon, Jan 4, 2016 at 11:22 AM, dcode notifications@github.com wrote:

@gconnell https://github.com/gconnell that is an astute observation.
CentOS 7.x includes localhost for both IPv4 and IPv6 loopback. This has
bit me in butt a couple times before.

I just checked, and that's not the case, however. When I test using
openssl directly, it works (I get a connected socket and certificate
validates):

openssl s_client -key /etc/stenographer/certs/client_key.pem -cert /etc/stenographer/certs/client_cert.pem -CAfile /etc/stenographer/certs/server_cert.pem -showcerts -connect 127.0.0.1:1234
CONNECTED(00000003)
depth=0 O = Stenographer, CN = 127.0.0.1

verify return:1

Certificate chain
0 s:/O=Stenographer/CN=127.0.0.1
i:/O=Stenographer/CN=127.0.0.1
-----BEGIN CERTIFICATE-----
///// TRIMMED FOR BREVITY //////

-----END CERTIFICATE-----

Server certificate
subject=/O=Stenographer/CN=127.0.0.1

issuer=/O=Stenographer/CN=127.0.0.1

Acceptable client certificate CA names
/O=Stenographer/CN=127.0.0.1

Server Temp Key: ECDH, prime256v1, 256 bits

SSL handshake has read 2326 bytes and written 1504 bytes

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 7200425460A3A9BFA96F2A97120918653741AFA7FA2E309CA1B1D07747551BD1
Session-ID-ctx:
Master-Key: 1189080494B3A5FBCB7A198D117F4787358B0E5C1B6DEBB9CE5D4485E09D72310165361BB0F2277F5963314A5CC4A565
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket:
////// TRIMMED FOR BREVITY ///////

Start Time: 1451930274
Timeout   : 300 (sec)
Verify return code: 0 (ok)

If I manually run it in curl, I get the following

[vagrant@simplerockbuild ~]$ curl -iv --cacert /etc/stenographer/certs/server_cert.pem --cert /etc/stenographer/certs/client_cert.pem --key /etc/stenographer/certs/client_key.pem https://localhost:1234/

  • About to connect() to localhost port 1234 (#0)
  • Trying 127.0.0.1...
  • Connected to localhost (127.0.0.1) port 1234 (#0)
  • Initializing NSS with certpath: sql:/etc/pki/nssdb
  • CAfile: /etc/stenographer/certs/server_cert.pem
    CApath: none
  • Server certificate:
  • subject: CN=127.0.0.1,O=Stenographer
  • start date: Jan 04 17:54:08 2016 GMT
  • expire date: Jan 03 17:54:08 2017 GMT
  • common name: 127.0.0.1
  • issuer: CN=127.0.0.1,O=Stenographer
  • NSS error -8101 (SEC_ERROR_INADEQUATE_CERT_TYPE)
  • Certificate type not approved for application.
  • Closing connection 0
    curl: (60) Certificate type not approved for application.
    More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

I found an issue with Firefox that sounds related (link
https://support.mozilla.org/en-US/questions/1019364). The user suggests
that the CA cert cannot have an extended usage. Not sure if that change
occurred in curl. I'll dig in more there.

curl --version
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.19.1 Basic ECC zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz

—
Reply to this email directly or view it on GitHub
#124 (comment)
.

dcode commented

I've dug more, I think I know the fix here. This is definitely issue after mucking with some curl-fu some more.

Need to generate another cert, for the CA. It looks like you just have to change the third parameter of x509.CreateCertificate certs.go, L81 to point to a CA cert. When generating the CA cert, you point it to the template as is currently done. It's important that the CA cert has not extended key usage

You then just have to change env.go, L74 to point to the new CA cert.

I've hacked together some code on the concepts that I think are right. It seems to have compiled, but I'm a noob at Go...so... Please review and... verbosely correct me :)

gconnell commented

I believe this is now fixed. Please reopen if not.