#1416 Problem with CRMF request via CLI
Closed: migrated 3 years ago by dmoluguw. Opened 8 years ago by edewata.

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.


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

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

Per Bug Triage of 05/05/2016: 10.4

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

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

Metadata Update from @edewata:
- Issue set to the milestone: FUTURE

7 years ago

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

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

5 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/1977

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