Problem with CRMF request via CLI

[pki-bot]

This issue was migrated from Pagure Issue #1416. Originally filed by edewata (@edewata) on 2015-06-13 18:59:20:

• Assigned to nobody
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=1251581

---

In Firefox 34 when enrolling a certificate using Manual User Signing & Encryption Certificates Enrollment (caDualCert) profile, which uses CRMF request, the server will generate two requests, and thus two certificates:

Extensions:
    Identifier: Authority Key Identifier - 2.5.29.35
        Critical: no
        Key Identifier:
            21:9A:6E:2D:CD:FE:EB:15:FD:0B:6C:A6:62:B9:42:99:
            B8:A3:C2:E7
    Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1
        Critical: no
        Access Description:
            Method 0: ocsp
            Location 0: URIName: http://server.example.com:8080/ca/ocsp
    Identifier: Key Usage: - 2.5.29.15
        Critical: yes
        Key Usage:
            Key Encipherment
    Identifier: Extended Key Usage: - 2.5.29.37
        Critical: no
        Extended Key Usage:
            1.3.6.1.5.5.7.3.2
            1.3.6.1.5.5.7.3.4

and

Extensions:
    Identifier: Authority Key Identifier - 2.5.29.35
        Critical: no
        Key Identifier:
            21:9A:6E:2D:CD:FE:EB:15:FD:0B:6C:A6:62:B9:42:99:
            B8:A3:C2:E7
    Identifier: Key Usage: - 2.5.29.15
        Critical: yes
        Key Usage:
            Digital Signature
            Non Repudiation
    Identifier: Extended Key Usage: - 2.5.29.37
        Critical: no
        Extended Key Usage:
            1.3.6.1.5.5.7.3.2
            1.3.6.1.5.5.7.3.4

However, when the CRMF request is submitted via CRMFPopClient, the server will only generate just one request and one certificate (with an additional extension):

$ CRMFPopClient -d ~/.dogtag/nssdb/ -p Secret123 -n uid=testuser -f caDualCert\
 -b transport.pem -m $HOSTNAME:8080 -u testuser -r testuser

Extensions:
    Identifier: Authority Key Identifier - 2.5.29.35
        Critical: no
        Key Identifier:
            75:2C:77:A1:C8:76:7B:C9:F6:34:58:6A:80:D5:32:C5:
            73:4D:28:2C
    Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1
        Critical: no
        Access Description:
            Method 0: ocsp
            Location 0: URIName: http://server.example.com:8080/ca/ocsp
    Identifier: Key Usage: - 2.5.29.15
        Critical: yes
        Key Usage:
            Key Encipherment
    Identifier: Extended Key Usage: - 2.5.29.37
        Critical: no
        Extended Key Usage:
            1.3.6.1.5.5.7.3.2
            1.3.6.1.5.5.7.3.4
    Identifier: Subject Alternative Name - 2.5.29.17
        Critical: no
        Value:
            RFC822Name: $request.requestor_email$

Similarly, with PKI CLI (which shares the code with CRMFPopClient) the server also generates only one request and one certificate:

$ pki -c Secret123 client-cert-request uid=testuser --profile caDualCert\
 --type crmf --transport transport.pem

Extensions:
    Identifier: Authority Key Identifier - 2.5.29.35
        Critical: no
        Key Identifier:
            75:2C:77:A1:C8:76:7B:C9:F6:34:58:6A:80:D5:32:C5:
            73:4D:28:2C
    Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1
        Critical: no
        Access Description:
            Method 0: ocsp
            Location 0: URIName: http://server.example.com:8080/ca/ocsp
    Identifier: Key Usage: - 2.5.29.15
        Critical: yes
        Key Usage:
            Key Encipherment
    Identifier: Extended Key Usage: - 2.5.29.37
        Critical: no
        Extended Key Usage:
            1.3.6.1.5.5.7.3.2
            1.3.6.1.5.5.7.3.4

Ideally the CLI should generate requests and certificates identical to the ones produced using Firefox.

Proposed milestone: since the functionality is no longer supported in the latest Firefox, the CLI should be fixed soon in 10.2.x.

[pki-bot]

Comment from mharmsen (@mharmsen) at 2015-06-15 21:07:57

Per CS/DS meeting of 06/15/2015: 10.3

[pki-bot]

Comment from edewata (@edewata) at 2015-08-19 20:08:34

According to jmagne the workaround is to submit two separate requests.

[pki-bot]

Comment from mharmsen (@mharmsen) at 2016-05-06 22:00:41

Per Bug Triage of 05/05/2016: 10.4

[pki-bot]

Comment from edewata (@edewata) at 2016-11-30 22:35:01

The workaround is to use caSigningUserCert instead of caDualCert. See http://pki.fedoraproject.org/wiki/Certificate_Key_Archival.

[pki-bot]

Comment from mharmsen (@mharmsen) at 2016-12-01 20:29:13

Per Offline Triage of 11/30/2016-12/01/2016: FUTURE - minor

[pki-bot]

Comment from edewata (@edewata) at 2017-02-27 14:09:39

Metadata Update from @edewata:

• Issue set to the milestone: FUTURE

[pki-bot]

Comment from mharmsen (@mharmsen) at 2018-04-13 18:37:43

Per 10.5.x/10.6 Triage: FUTURE

mharmsen: as this issue is quite old, it needs to be re-verified with more recent bits to see if it is still a problem

[pki-bot]

Comment from mharmsen (@mharmsen) at 2018-04-13 18:37:44

Metadata Update from @mharmsen:

• Custom field feature adjusted to None
• Custom field proposedmilestone adjusted to None
• Custom field reviewer adjusted to None
• Custom field version adjusted to None
• Issue close_status updated to: None