Chrome reports error 207 (invalid certificate) when importing new client certificate after browser-based enrolment.
According to https://productforums.google.com/forum/#!topic/chrome/xAk3G8ClKYI it expects DER, not PEM.
Firefox (and presumably other browsers?) work just fine.
A potential solution would be to inspect the User-Agent and serve up DER for Chrome.
Per CS/DS meeting of 11/02/2015: 10.4
NOTE: There has been a customer RFE for support of Chrome in the 10.3 timeframe.
Per CS/DS Leads meeting of 11/03/2015: 10.3 - major
NOTE: This was determined for this ticket only; more comprehensive Chrome "support" discussions are still ongoing.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1301755 (Red Hat Certificate System)
Per discussions in IRC on 04/14/2016:
nkinder recommended that mharmsen spend time testing out the end-entity interface with chrome in the 10.3.0 milestone, and file and address any additional tickets as needed.
re-assigning this ticket to mharmsen, however, ftweedal can continue to address the initial issue raised within this ticket
Associated with PKI TRAC Ticket #2306 - Chrome Can Not Submit EC Client Cert Requests
I suspect that at least one problem may be related to the following ticket:
I need to check with the NSS folks, but my guess is that Google Chrome only supports the NSS shared mysql database model (cert9.db, key4.db); Dogtag does not yet support this model, but rather utilizes the legacy Berkeley DB model (cert8.db, key3.db).
NOTE: When I was testing 'google-chrome-stable-50.0.2661.94-1.x86_64' on a Fedora 23 machine, I was able to manually import a PKCS #7 representation of the CA certificate chain as well as the SSL Server certificate. Although I found no local client NSS databases under the '~/.config/google-chrome' directory, I was able to confirm that the two certificates were installed in the '/etc/pki/nssdb/cert9.db' file (this must be done as the user, not as root, since the shared NSS database may contain the certs from multiple users): # cd /etc/pki/nssdb/ # certutil -d . -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI # certutil -d sql:. -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CA Signing Certificate CT,C,C pki.usersys.redhat.com ,, # certutil -d sql:. -n "CA Signing Certificate" -L Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=CA Signing Certificate,O=usersys.redhat.com Security Doma in" Validity: Not Before: Tue May 10 21:31:32 2016 Not After : Sat May 10 21:31:32 2036 Subject: "CN=CA Signing Certificate,O=usersys.redhat.com Security Dom ain" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: c7:a8:a3:bd:04:6a:cb:ec:7f:38:6f:d6:66:9b:18:0a: 01:2d:98:70:09:f9:95:9a:78:b4:f3:72:64:32:8b:a1: 66:c6:98:bc:82:cf:37:84:07:58:62:75:ae:d3:ce:16: c1:91:12:ed:eb:ef:4f:b0:3c:4c:25:07:16:19:f7:51: e7:87:75:cf:a2:39:a4:8e:50:3e:11:d5:78:a1:92:42: ef:bc:4c:e5:4e:97:49:5f:d8:d4:06:f4:24:6e:48:90: b1:64:54:05:11:d9:91:39:1a:33:4e:63:7f:8d:a3:07: 61:ec:08:92:ed:37:ea:14:3d:2b:50:33:36:7b:ec:33: 28:02:66:18:14:05:99:84:59:ce:10:f1:10:b6:93:a2: 94:aa:68:6c:56:52:64:65:d2:ac:ff:56:3d:8e:86:ef: f9:51:45:9b:04:0e:b0:96:51:ab:7d:ad:8f:8d:ba:b6: 02:a3:1c:0d:5c:a9:36:ad:e5:ff:99:0e:9c:cb:ac:0b: 03:dc:a0:fa:d0:73:d1:4d:aa:fb:c0:fb:ac:7e:9b:0c: 29:1c:07:66:09:1a:e8:11:7b:d2:6c:04:4b:1e:d1:ea: a0:1d:24:89:70:b2:20:b6:15:fa:5a:0f:f4:3d:10:f4: c7:13:fe:8d:62:5e:7f:48:99:63:85:e2:b1:e9:34:bf Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: 3d:94:4f:57:25:3a:4d:fc:a6:83:a0:5f:f8:76:f1:16: 0c:74:f8:fe Name: Certificate Basic Constraints Critical: True Data: Is a CA with no maximum path length. Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Certificate Signing CRL Signing Name: Certificate Subject Key ID Data: 3d:94:4f:57:25:3a:4d:fc:a6:83:a0:5f:f8:76:f1:16: 0c:74:f8:fe Name: Authority Information Access Method: PKIX Online Certificate Status Protocol Location: URI: "http://pki.usersys.redhat.com:8080/ca/ocsp" Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: 3a:d2:90:98:03:af:00:dd:88:58:80:ff:c3:9a:02:75: ac:0b:93:ca:dd:e6:ea:2c:28:7b:40:26:af:58:4b:06: 61:68:23:da:9f:48:fa:45:e3:5b:03:4d:33:d3:f1:bc: 24:cc:ff:98:ee:dc:31:6b:c4:02:02:b3:c3:71:d0:98: ff:0a:19:b5:20:e9:e5:cf:33:a4:ff:b7:c4:3d:f5:1f: 82:39:32:8c:20:3a:30:2b:dc:e3:94:6f:b7:af:06:35: 61:e8:22:e8:68:8f:1d:99:c3:62:5e:d3:a7:29:ee:74: b1:ae:e7:e8:2a:54:c1:86:35:09:1a:22:2f:32:5f:0e: 65:2f:00:7e:e2:ae:53:b3:f3:e3:32:c5:d5:fa:25:b2: 89:9c:0e:4c:7f:94:6f:1e:dd:fe:1c:0e:0f:67:1c:18: e2:07:57:cb:b8:e0:3c:af:49:d8:7e:59:b6:0e:28:12: f2:7e:d0:53:2b:d0:d3:1e:8e:98:3c:7c:70:5a:3e:96: ea:26:6e:2d:f0:cb:d1:3f:65:91:d2:e6:1e:e9:9b:63: ab:86:32:dc:c3:eb:a2:80:cd:fa:f7:58:25:44:87:89: a6:62:49:38:f3:05:a5:7a:8d:b4:5f:44:9e:0f:48:5b: 38:95:cd:a8:8f:8e:3f:8a:ff:30:22:2d:c9:46:3d:df Fingerprint (SHA-256): 3C:BC:A6:B6:F1:7B:F5:CC:AE:10:2C:8A:4F:45:65:6F:95:4C:49:F9:62:37:75:84:2F:7D:F2:E6:97:11:26:EF Fingerprint (SHA1): 5B:40:40:1E:B2:11:E8:8D:1D:18:9F:E0:FA:E5:D0:A8:96:89:E5:D7 Certificate Trust Flags: SSL Flags: Valid CA Trusted CA Trusted Client CA Email Flags: Valid CA Trusted CA Object Signing Flags: Valid CA Trusted CA # certutil -d sql:. -n "pki.usersys.redhat.com" -L Certificate: Data: Version: 3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=CA Signing Certificate,O=usersys.redhat.com Security Doma in" Validity: Not Before: Tue May 10 21:31:33 2016 Not After : Mon Apr 30 21:31:33 2018 Subject: "CN=pki.usersys.redhat.com,O=usersys.redhat.com Security Dom ain" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: c7:64:66:94:43:35:c9:6f:19:3a:aa:a8:1b:60:ad:bc: b0:01:69:b4:1b:c3:e6:09:8a:1c:a0:1d:14:f9:f0:3e: b1:d0:c7:46:c9:5b:2b:fd:a4:18:07:ee:2e:20:ba:07: 51:21:32:fc:57:6e:1a:a9:a2:46:6a:fd:24:b7:05:45: 16:ee:ef:47:73:96:e1:0f:4b:f9:a9:70:9d:e7:8b:da: 6a:86:df:83:c0:0e:db:c9:0e:75:58:33:71:c3:b7:d0: 9b:d8:02:7b:43:59:cf:6d:ae:88:69:6f:5f:19:7e:8b: 82:a4:64:96:aa:19:75:f0:a7:4e:0b:d4:bc:2a:a1:12: 24:34:2e:1c:45:a9:40:d2:07:47:33:1e:79:20:43:9e: 13:6e:b2:53:ef:bf:31:bf:e8:9a:f2:da:91:d8:5a:b4: 72:25:f2:85:17:83:33:8f:ec:37:ca:b8:60:f9:62:63: 57:54:7a:74:91:61:54:6b:cd:8a:49:4f:87:d5:48:59: 66:4a:56:2e:b3:c3:3f:82:41:b5:66:c0:e4:7e:b8:5d: f2:b6:46:b3:22:3d:6a:1a:be:ba:17:36:60:49:76:ed: 15:90:8c:3f:19:fb:ed:73:f3:93:2e:43:0b:bc:15:ca: 9a:dc:18:9d:e5:ea:c5:57:59:1f:c6:4f:5a:b8:40:95 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: 3d:94:4f:57:25:3a:4d:fc:a6:83:a0:5f:f8:76:f1:16: 0c:74:f8:fe Name: Authority Information Access Method: PKIX Online Certificate Status Protocol Location: URI: "http://pki.usersys.redhat.com:8080/ca/ocsp" Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Name: Extended Key Usage TLS Web Server Authentication Certificate Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: 05:e2:fa:3e:99:24:05:bf:65:7c:ad:fe:5c:37:12:13: 26:46:9f:1a:49:d0:77:8c:bb:1d:57:37:de:ae:f3:14: 27:61:06:68:29:94:15:c7:90:a9:97:5d:12:90:f8:52: 32:e2:b5:1a:00:61:cd:17:8f:81:ef:83:eb:a8:46:41: 18:8c:47:dd:66:5f:25:49:6d:33:88:8d:57:f1:83:bc: 03:7a:d0:a0:e1:c7:14:78:98:6b:9f:04:fa:a3:96:03: e8:6c:00:d2:63:63:b3:0f:33:1b:db:cb:5b:09:f1:92: ee:30:17:70:d0:02:16:b9:84:a9:7b:0d:3b:09:e7:c5: 97:57:a1:6c:fc:0d:df:ce:f3:36:ec:3d:d7:10:60:19: f1:c5:97:84:e3:46:1d:57:1c:84:12:f7:1c:51:68:f7: de:a5:a2:2f:80:77:b6:b3:f2:f7:d5:3a:03:72:a1:f6: f2:57:77:39:c2:6b:01:e8:dc:6c:95:2b:d9:5e:5f:92: 94:3e:27:74:0c:76:56:ac:61:0d:9d:25:d2:8d:a3:ed: fc:8a:f1:44:3a:1a:aa:7b:31:cf:d3:15:c8:b4:18:5f: cc:f4:ba:1a:bc:fa:33:b4:f6:40:1e:0b:3c:54:58:6b: 0f:a1:1e:29:c6:fc:7a:45:51:d0:21:5d:ec:08:1c:fb Fingerprint (SHA-256): 9D:B0:61:37:95:57:EE:5B:D1:E6:99:D7:EE:AE:66:55:21:12:8F:96:74:D6:9A:32:CF:8C:17:2D:E7:58:40:95 Fingerprint (SHA1): 3A:B3:FA:6B:C0:0A:B7:DD:A7:2A:42:F8:05:06:D8:30:A0:BD:08:38 Certificate Trust Flags: SSL Flags: Email Flags: Object Signing Flags:
Upon further investigation, I did find local client NSS databases under the '~/.pki/nssdb/' directory, and I was able to confirm that the two certificates were also installed here.
I did another test which showed that it this local directory structure did not exist, the directories and NSS databases (cert9.db, key4.db, and pkcs11.txt) are created when chrome is launched initially.
As explained above, these NSS databases are in the shared SQL format which Dogtag does not currently support.
After discussions with the NSS folks, I checked out chrome, and searching through the source appears to verify my hypothesis: ``` src/crypto/nss_util.cc: ... // USE_NSS_CERTS means NSS is used for certificates and platform integration. ... NSSInitSingleton() : tpm_token_enabled_for_nss_(false), initializing_tpm_token_(false), chaps_module_(NULL), root_(NULL) { ...
// Use the system certificate store, so initialize NSS without database. nodb_init = true;
if (nodb_init) {
... } else {
base::FilePath database_dir = GetInitialConfigDirectory(); if (!database_dir.empty()) { // This duplicates the work which should have been done in // EarlySetupForNSSInit. However, this function is idempotent so // there's no harm done. UseLocalCacheOfNSSDatabaseIfNFS(database_dir); // Initialize with a persistent database (likely, ~/.pki/nssdb). // Use "sql:" which can be shared by multiple processes safely. std::string nss_config_dir = base::StringPrintf("sql:%s", database_dir.value().c_str());
status = NSS_Init(nss_config_dir.c_str());
status = NSS_InitReadWrite(nss_config_dir.c_str());
}
...
ScopedPK11Slot OpenSoftwareNSSDB(const base::FilePath& path, const std::string& description) { const std::string modspec = base::StringPrintf("configDir='sql:%s' tokenDescription='%s'", path.value().c_str(), description.c_str()); PK11SlotInfo* db_slot = SECMOD_OpenUserDB(modspec.c_str()); if (db_slot) { if (PK11_NeedUserInit(db_slot)) PK11_InitPin(db_slot, NULL, NULL); } else { LOG(ERROR) << "Error opening persistent database (" << modspec << "): " << GetNSSErrorMessage(); } return ScopedPK11Slot(db_slot); } ...
Finally, as a last attempt to see if I could circumvent the Chrome behaviour, I tried the following:
# mkdir ~/.pki/nssdb # cd ~/.pki/nssdb # certutil -d . -N --empty-password # ls cert8.db key3.db secmod.db
I launched chrome (basically for the first time), and checked to see if it would skip creation of the SQL databases, but it did not:
# cd ~/.pki/nssdb # ls cert8.db cert9.db key3.db key4.db pkcs11.txt secmod.db
Comments # 10, 11, 12, and 13 were a red herring.
It was discovered by nkinder that Chrome had turned off keygen by default:
and, supplied a workaround:
Once the radio button was pressed, I was able to successfully issue a valid certificate request and enroll.
A Wiki needs to be generated which explains how to setup Chrome.
The following URLs should be referenced:
Shift-Ctrl-J to display javascript console:
As this is all Wiki documentation, moving to Milestone 10.3.1.
Metadata Update from @ftweedal: - Issue assigned to mharmsen - Issue set to the milestone: 1.0 TASKS
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/1807
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Metadata Update from @dmoluguw: - Issue close_status updated to: migrated - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.