Bug #6877
closednsCertType "Server" property of a certificate is not detected if additional nsCertType flags are also set
100%
Description
Using a GoDaddy server certificate. The server has both TLS Web Server Authentication and TLS Web Client Authentication EKU OIDs. Yet, the certificate manager screen states the certificate is not a server certificate.
Here is the certificate:
Certificate: Data: Version: 3 (0x2) Serial Number: 78:69:e6:2f:b7:82:62:1a Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2 Validity Not Before: Aug 31 17:13:39 2016 GMT Not After : Aug 31 17:13:39 2017 GMT Subject: OU=Domain Control Validated, CN=cloudmgr.cloudtransform.ca Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:d9:4e:02:2b:0a:6e:28:79:a6:b3:c4:a7:95:11: 2b:4c:f3:ff:60:2d:44:29:18:f8:97:1a:1b:92:9b: fb:4b:51:a5:ed:8c:57:99:8c:43:6c:4b:01:64:d4: b6:ea:73:3b:64:2f:d8:84:33:7d:67:09:71:e2:fd: 81:46:af:32:fb:5c:bc:8d:01:1f:3b:43:d4:95:01: 6a:f4:c8:1d:4b:84:93:35:57:88:7d:c8:3a:36:b2: af:bc:96:9a:7b:7c:98:29:d5:12:26:55:51:a0:d2: 2b:77:a2:31:4e:cf:20:90:35:f0:00:89:1f:1c:bb: 08:f8:1f:9a:e2:a8:5e:ec:79:fa:27:aa:6a:f6:e9: 54:e2:6b:98:9e:cc:3c:39:cd:fe:2e:50:82:66:7f: fc:4b:7c:35:42:0a:a8:df:ae:d5:dc:55:43:f1:4d: 10:e6:a6:f8:b3:2f:7a:2d:2b:9c:8b:af:dc:16:23: d6:25:3e:62:90:03:78:87:68:73:1e:22:98:0b:3e: e7:b7:64:e6:e4:19:a2:56:73:8b:0a:62:06:fc:12: cf:9b:59:a5:be:ed:3a:0d:03:b6:21:b9:c9:ce:1e: e6:83:1d:3b:9c:5f:9b:23:a5:65:e9:d0:9a:29:68: 45:5c:93:b4:44:2d:c7:db:af:87:7b:bd:42:0b:46: b0:19 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 CRL Distribution Points: Full Name: URI:http://crl.godaddy.com/gdig2s1-295.crl X509v3 Certificate Policies: Policy: 2.16.840.1.114413.1.7.23.1 CPS: http://certificates.godaddy.com/repository/ Policy: 2.23.140.1.2.1 Authority Information Access: OCSP - URI:http://ocsp.godaddy.com/ CA Issuers - URI:http://certificates.godaddy.com/repository/gdig2.crt X509v3 Authority Key Identifier: keyid:40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE X509v3 Subject Alternative Name: DNS:cloudmgr.cloudtransform.ca, DNS:www.cloudmgr.cloudtransform.ca X509v3 Subject Key Identifier: 40:E1:91:BD:E9:1C:BF:9A:84:02:C5:06:B8:8C:A5:10:8D:8D:33:8E Signature Algorithm: sha256WithRSAEncryption 80:77:6f:1b:66:91:e9:9f:92:0c:2c:b2:21:b1:f7:e2:15:4a: e7:c0:88:bb:a4:80:8c:f8:60:6f:62:8d:87:b8:04:f5:1c:67: 83:45:d4:28:62:ac:d4:50:6b:46:7a:c0:28:7a:f9:f6:dc:19: 52:24:27:0f:03:c2:22:c2:11:b2:38:55:cc:af:c0:2b:de:9e: 9f:42:90:cd:0a:43:5c:4d:63:40:5b:97:3e:d4:54:6d:8c:63: ef:e6:8a:49:5b:ae:22:1e:64:14:32:1d:60:b8:51:0c:40:42: 46:cf:1f:34:65:1b:61:58:4f:07:69:62:81:b7:57:04:9a:a2: 23:c3:70:9d:80:75:f6:06:76:4f:52:33:fd:c2:c7:81:51:0b: 12:3f:10:72:26:54:8d:4f:91:f0:0e:1a:66:3e:d7:86:46:4e: 9f:3c:4f:3a:66:39:3e:86:ca:d0:9c:f1:69:f9:f1:b7:7b:7d: 76:7c:6d:d1:0d:e0:9c:ed:1e:0b:d2:2a:96:96:29:51:88:a4: 54:11:d7:7d:8e:64:f1:c1:a7:8f:6e:ea:35:ec:81:31:02:84: e9:11:7a:17:bf:3f:ff:c4:cb:3e:ae:54:cb:ff:5e:05:c7:b2: 05:22:2e:59:eb:4a:de:08:e5:85:a8:9a:6e:80:85:14:ac:73: 3f:ca:0a:e9
Files
Updated by Jim Pingle about 8 years ago
- Status changed from New to Rejected
Those are both authentication attributes, not the server property.
The GUI checks the cert to see if the nsCertType extension is set to "SSL Server", and reports if it is found or not.
Updated by Bruno Grossmann about 8 years ago
OK. However, let me point out that, according to https://www.openssl.org/docs/manmaster/apps/x509v3_config.html, the nsCertType extension is "non standard, Netscape specific and largely obsolete".
Updated by Jim Pingle about 8 years ago
That means nothing to how it's used on pfSense. One of the primary uses of certificates on pfSense is OpenVPN, and OpenVPN uses that property when validating server certificates. If we keyed off of some other property, it would lead to confusion and problems with clients in OpenVPN.
When creating a server certificate in pfSense we do also set extendedKeyUsage=serverAuth,1.3.6.1.5.5.8.2.2
but the primary indicator for the GUI to say "Server: Yes" is nsCertType because that reflects the type directly and it's significant to OpenVPN.
There could be another flag (e.g. ServerAuth: Yes/No) but that area is already a bit cluttered.
Updated by Kill Bill about 8 years ago
Well, this does not work properly even with the nsCertType set. Example:
Certificate: Data: Version: 3 (0x2) Serial Number: 27:5a:ca:53:65:40:ca:6c:24:f7:b6:7c:37:b0:e5:1b Signature Algorithm: sha256WithRSAEncryption Issuer: C=PL, O=Unizeto Technologies S.A., OU=Certum Certification Authority, CN=Certum Domain Validation CA SHA2 Validity Not Before: Nov 16 12:58:32 2016 GMT Not After : Nov 16 12:58:32 2017 GMT Subject: C=CZ, CN=*.ckcesta.cz/emailAddress=admin@ckcesta.cz Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:b5:d5:01:72:f4:18:1b:dc:19:17:a0:39:67:5b: 9a:cd:0c:73:92:de:a3:12:c7:59:b8:1c:63:47:ed: 4d:fb:8d:31:f5:a8:7c:7e:1c:17:61:58:d3:1e:7d: eb:c2:30:19:21:bd:48:d3:f3:9d:d3:13:3e:81:0e: 85:94:fa:26:1f:3a:32:4b:77:7f:ca:67:52:2a:4b: 10:43:a7:df:4c:61:56:b3:b0:fa:9d:90:83:91:1d: f5:c6:d1:95:5d:79:3e:27:29:d2:c5:23:f3:ca:c4: d1:b3:4e:f2:e6:34:73:d8:ff:db:39:6f:1d:e0:1a: 0a:4e:e6:22:d2:2d:5c:15:f7:5e:d3:b8:0b:9e:1f: 11:ec:96:c2:f1:f3:31:2e:3b:54:81:ec:c0:01:cb: a3:9b:21:85:f9:67:f3:59:3f:8a:f8:b2:b8:4d:c8: 25:27:bf:f0:6e:86:18:fd:ae:36:ab:4f:e3:cf:c5: 2d:75:8e:b4:ed:e9:d9:e3:e2:a4:66:92:11:d5:9b: 35:4e:9c:c0:f1:9e:1a:2b:e5:4c:1c:ce:e3:68:50: 38:88:33:dc:c3:cc:78:ab:68:4c:31:d5:fe:ec:fd: 1d:56:1f:ae:ce:54:31:88:5b:7f:b3:7c:21:1b:b3: bd:cf:91:76:9e:19:d9:98:03:1e:30:d4:2f:62:c0: 84:cd Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 CRL Distribution Points: Full Name: URI:http://crl.certum.pl/dvcasha2.crl Authority Information Access: OCSP - URI:http://dvcasha2.ocsp-certum.com CA Issuers - URI:http://repository.certum.pl/dvcasha2.cer X509v3 Authority Key Identifier: keyid:E5:31:AD:BF:3A:11:96:F4:83:BC:50:3C:D4:B7:90:9B:90:EE:DE:25 X509v3 Subject Key Identifier: 2E:96:A7:89:3A:CB:00:67:BD:C8:15:1F:7B:5E:68:9C:99:75:AA:14 X509v3 Issuer Alternative Name: email:dvcasha2@certum.pl X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Certificate Policies: Policy: 1.2.616.1.113527.2.5.1.3 User Notice: Organization: Unizeto Technologies S.A. Number: 2 Explicit Text: Usage of this certificate is strictly subjected to the CERTUM Certification Practice Statement (CPS) incorporated by reference herein and in the repository at https://www.certum.pl/repository. X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication Netscape Cert Type: SSL Client, SSL Server X509v3 Subject Alternative Name: DNS:*.ckcesta.cz, DNS:ckcesta.cz Signature Algorithm: sha256WithRSAEncryption 0c:7d:ad:b1:bd:16:dd:e1:7a:ef:ef:cc:f1:7e:a0:5a:3f:49: af:5b:4c:0b:cc:cd:b3:db:3b:db:f7:77:90:5b:57:f7:2f:00: c8:03:82:97:17:4a:8a:ac:4d:63:3f:ce:f9:75:ee:33:f1:2b: 61:2a:d1:01:19:a2:0f:a4:8b:fb:26:7b:21:21:5a:1b:fb:e2: 63:02:d5:da:b3:6d:e1:06:1f:ba:a0:49:ea:4a:4e:78:90:9d: 81:99:9c:e8:08:d0:95:a6:93:b4:c8:8e:ee:24:11:86:5e:0b: f4:55:e6:d9:b9:5b:05:fc:81:5e:17:5b:50:45:0e:90:22:c1: 94:de:a4:89:d9:87:31:40:97:c5:33:12:6f:49:5d:64:ea:c7: 8c:0c:47:74:ca:08:bb:06:c6:52:bb:a5:61:68:c4:28:2c:f2: 2c:ae:d7:25:c6:fb:a8:e3:f9:18:5c:08:d3:1b:71:3d:e9:18: df:14:af:0e:7e:54:a1:f2:42:40:26:52:b0:77:aa:19:7e:be: 66:fa:6b:6b:64:ce:c1:8e:06:1b:a5:81:e4:16:06:8d:f0:ad: c9:45:90:f2:fd:01:01:33:57:9e:98:2c:2e:fb:65:b8:af:62: 11:75:d0:f5:45:c1:c2:96:1d:92:22:98:5b:bb:d5:0f:2f:c7: 99:74:7f:f4 -----BEGIN CERTIFICATE----- MIIF8DCCBNigAwIBAgIQJ1rKU2VAymwk97Z8N7DlGzANBgkqhkiG9w0BAQsFADCB hTELMAkGA1UEBhMCUEwxIjAgBgNVBAoTGVVuaXpldG8gVGVjaG5vbG9naWVzIFMu QS4xJzAlBgNVBAsTHkNlcnR1bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEpMCcG A1UEAxMgQ2VydHVtIERvbWFpbiBWYWxpZGF0aW9uIENBIFNIQTIwHhcNMTYxMTE2 MTI1ODMyWhcNMTcxMTE2MTI1ODMyWjBFMQswCQYDVQQGEwJDWjEVMBMGA1UEAwwM Ki5ja2Nlc3RhLmN6MR8wHQYJKoZIhvcNAQkBFhBhZG1pbkBja2Nlc3RhLmN6MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtdUBcvQYG9wZF6A5Z1uazQxz kt6jEsdZuBxjR+1N+40x9ah8fhwXYVjTHn3rwjAZIb1I0/Od0xM+gQ6FlPomHzoy S3d/ymdSKksQQ6ffTGFWs7D6nZCDkR31xtGVXXk+JynSxSPzysTRs07y5jRz2P/b OW8d4BoKTuYi0i1cFfde07gLnh8R7JbC8fMxLjtUgezAAcujmyGF+WfzWT+K+LK4 TcglJ7/wboYY/a42q0/jz8UtdY607enZ4+KkZpIR1Zs1TpzA8Z4aK+VMHM7jaFA4 iDPcw8x4q2hMMdX+7P0dVh+uzlQxiFt/s3whG7O9z5F2nhnZmAMeMNQvYsCEzQID AQABo4ICmTCCApUwDAYDVR0TAQH/BAIwADAyBgNVHR8EKzApMCegJaAjhiFodHRw Oi8vY3JsLmNlcnR1bS5wbC9kdmNhc2hhMi5jcmwwcQYIKwYBBQUHAQEEZTBjMCsG CCsGAQUFBzABhh9odHRwOi8vZHZjYXNoYTIub2NzcC1jZXJ0dW0uY29tMDQGCCsG AQUFBzAChihodHRwOi8vcmVwb3NpdG9yeS5jZXJ0dW0ucGwvZHZjYXNoYTIuY2Vy MB8GA1UdIwQYMBaAFOUxrb86EZb0g7xQPNS3kJuQ7t4lMB0GA1UdDgQWBBQulqeJ OssAZ73IFR97XmicmXWqFDAdBgNVHRIEFjAUgRJkdmNhc2hhMkBjZXJ0dW0ucGww DgYDVR0PAQH/BAQDAgWgMIIBFgYDVR0gBIIBDTCCAQkwggEFBgsqhGgBhvZ3AgUB AzCB9TCB8gYIKwYBBQUHAgIwgeUwIBYZVW5pemV0byBUZWNobm9sb2dpZXMgUy5B LjADAgECGoHAVXNhZ2Ugb2YgdGhpcyBjZXJ0aWZpY2F0ZSBpcyBzdHJpY3RseSBz dWJqZWN0ZWQgdG8gdGhlIENFUlRVTSBDZXJ0aWZpY2F0aW9uIFByYWN0aWNlIFN0 YXRlbWVudCAoQ1BTKSBpbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlIGhlcmVpbiBh bmQgaW4gdGhlIHJlcG9zaXRvcnkgYXQgaHR0cHM6Ly93d3cuY2VydHVtLnBsL3Jl cG9zaXRvcnkuMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjARBglghkgB hvhCAQEEBAMCBsAwIwYDVR0RBBwwGoIMKi5ja2Nlc3RhLmN6ggpja2Nlc3RhLmN6 MA0GCSqGSIb3DQEBCwUAA4IBAQAMfa2xvRbd4Xrv78zxfqBaP0mvW0wLzM2z2zvb 93eQW1f3LwDIA4KXF0qKrE1jP875de4z8SthKtEBGaIPpIv7JnshIVob++JjAtXa s23hBh+6oEnqSk54kJ2BmZzoCNCVppO0yI7uJBGGXgv0VebZuVsF/IFeF1tQRQ6Q IsGU3qSJ2YcxQJfFMxJvSV1k6seMDEd0ygi7BsZSu6VhaMQoLPIsrtclxvuo4/kY XAjTG3E96RjfFK8OflSh8kJAJlKwd6oZfr5m+mtrZM7BjgYbpYHkFgaN8K3JRZDy /QEBM1eemCwu+2W4r2IRddD1RcHClh2SIphbu9UPL8eZdH/0 -----END CERTIFICATE-----
Updated by Kill Bill about 8 years ago
Yeah, this cannot work
$crt = "-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----"; $crt_details = openssl_x509_parse($crt); var_dump($crt_details['extensions']['nsCertType']);
with the above certificate produces
[nsCertType] => SSL Client, SSL Server
while certs.inc (https://github.com/pfsense/pfsense/blob/master/src/etc/inc/certs.inc#L566) checks for
$purpose['server'] = ($crt_details['extensions']['nsCertType'] == "SSL Server") ? 'Yes': 'No';
See https://github.com/pfsense/pfsense/pull/3233 for a possible fix.
Updated by Jim Pingle about 8 years ago
- Subject changed from Wrong certificate property in certificate manager to nsCertType "Server" property of a certificate is not detected if additional nsCertType flags are also set
- Category set to Certificates
- Status changed from Rejected to Assigned
- Assignee set to Jim Pingle
- Priority changed from Low to Very Low
- Target version set to 2.4.0
- Affected Version set to All
- Affected Architecture All added
- Affected Architecture deleted (
)
I don't think I've ever seen one with both set, and practically there is rarely if ever a reason to do so. It's worth parsing properly, but it's uncommon.
Updated subject to match the discovered problem.
Updated by Jim Pingle about 8 years ago
- Status changed from Assigned to Feedback
- % Done changed from 0 to 100
Merged PR
Updated by Jim Pingle about 8 years ago
- Status changed from Feedback to Resolved
Looks good, thanks for testing!
Updated by Bruno Grossmann about 8 years ago
And in the same spirit, https://github.com/pfsense/pfsense/pull/3234