dogtagpki

Clone
Source Code
GIT

#1245 [WIKI]: Importing client certificate in Chrome fails
Closed: migrated 3 years ago by dmoluguw. Opened 9 years ago by ftweedal.

Closed: migrated
Reopen Issue

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

if !defined(USE_NSS_CERTS)

// Use the system certificate store, so initialize NSS without database.
nodb_init = true;

endif

if (nodb_init) {

...
} else {

if defined(USE_NSS_CERTS)

  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());

if defined(OS_CHROMEOS)

    status = NSS_Init(nss_config_dir.c_str());

else

    status = NSS_InitReadWrite(nss_config_dir.c_str());

endif

  }

...

if defined(USE_NSS_CERTS)

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.

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
7 years ago

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.

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)
3 years ago

Login to comment on this ticket.

Metadata
None
None
None
major
None
None
task
None
None
dminnich
None
None
Community
None
None
None
None
None
None
Wiki
None
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.