Bug 1808613
| Summary: | certmonger: man page for getcert-add-scep-ca -R option does not match implementation | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Graham Leggett <minfrin> |
| Component: | certmonger | Assignee: | Rob Crittenden <rcritten> |
| Status: | CLOSED ERRATA | QA Contact: | ipa-qe <ipa-qe> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.2 | CC: | ksiddiqu, myusuf, nalin, pcech, rcritten |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | 8.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | certmonger-0.79.7-8.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-04 02:51:52 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1825061 | ||
I think for backwards compatibility I'll need to leave -R/-cacert as the TLS cert chain and add a new option to specify the SCEP CA. I'm considering -S/--signingcacert or -I/--issuingcacert to specify the CA chain of the SCEP backend. Either way it may end up breaking something but I think this will be the least intrusive because certmonger should fall back to the detected CA value and ideally continue working as before. I can only assume that most SCEP installations don't use a different PKI for the web server than the CA since has always worked this way. Note to self: at the same time update the man page that relative paths are not allowed for all these certs. A reproducer for this is to use the Redwax Interop SCEP server which uses a web server cert signed by Let's Encrypt. # getcert add-scep-ca -c "Redwax Interop" -u https://interop.redwax.eu/test/simple/scep # getcert list-cas You should not have the fingerprints which means that certmonger wasn't able to contact the remote CA due to untrusted CA chain Fetch the three CA's you need from https://letsencrypt.org/certificates/ You need: 1. ISRG Root X1 (self-signed) 2. Let’s Encrypt Authority X3 (IdenTrust cross-signed) 3. Let’s Encrypt Authority X3 (Signed by ISRG Root X1) Put those into a file # getcert add-scep-ca -c "Redwax Interop" -u https://interop.redwax.eu/test/simple/scep -R /path/to/file # getcert list-cas There should be fingerprints now. Test that getting a certificate works # getcert request -f /etc/pki/tls/certs/test.example.com.cert -k /etc/pki/tls/private/test.example.com.key -c "Redwax Interop" -I test.example.com -D test.example.com -G rsa -g 2048 -u digitalSignature -u keyEncipherment -L challenge # getcert list -i test.example.com The request should eventually get to MONITORING Fixed in master: 230b640e67ea27db59d59dd7bef776638ac005dc You'll need to create the LE chain in the correct order, like: curl https://letsencrypt.org/certs/isrgrootx1.pem.txt > le.chain curl https://letsencrypt.org/certs/letsencryptauthorityx3.pem.txt >> le.chain curl https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt >> le.chain You can verify that the CA is reachable using: # /usr/libexec/certmonger/scep-submit -u https://interop.redwax.eu/test/simple/scep -c -R /path/to/le.chain It will return something like: AES POSTPKIOperation SHA-1 SHA-256 SHA-512 SCEPStandard version: certmonger-0.79.7-14.el8.x86_64 [root@master ~]# curl https://letsencrypt.org/certs/isrgrootx1.pem.txt > /etc/pki/tls/certs/le.chain % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:09 --:--:-- 0curl: (6) Could not resolve host: letsencrypt.org [root@master ~]# vi /etc/resolv.conf [root@master ~]# curl https://letsencrypt.org/certs/isrgrootx1.pem.txt > /etc/pki/tls/certs/le.chain % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1939 100 1939 0 0 1605 0 0:00:01 0:00:01 --:--:-- 1606 [root@master ~]# vi /etc/resolv.conf [root@master ~]# vi /etc/pki/tls/certs/le.chain [root@master ~]# curl https://letsencrypt.org/certs/letsencryptauthorityx3.pem.txt >> /etc/pki/tls/certs/le.chain % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1984 100 1984 0 0 1603 0 0:00:01 0:00:01 --:--:-- 1602 [root@master ~]# curl https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt >> /etc/pki/tls/certs/le.chain % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1647 100 1647 0 0 1360 0 0:00:01 0:00:01 --:--:-- 1360 [root@master ~]# /usr/libexec/certmonger/scep-submit -u https://interop.redwax.eu/test/simple/scep -c -R /etc/pki/tls/certs/le.chain AES POSTPKIOperation SHA-1 SHA-256 SHA-512 SCEPStandard [root@master ~]# getcert add-scep-ca -c "Redwax Interop" -u https://interop.redwax.eu/test/simple/scep -R /etc/pki/tls/certs/le.chain New CA "Redwax Interop" added. [root@master ~]# [root@master ~]# getcert list-cas -c "Redwax Interop" CA 'Redwax Interop': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/scep-submit -u https://interop.redwax.eu/test/simple/scep -R /etc/pki/tls/certs/le.chain SCEP CA certificate thumbprint (MD5): 9B3BB9A9 0EFDCDB9 3434F633 54240F40 SCEP CA certificate thumbprint (SHA1): 14AC57D3 5562DA67 0490F9C1 A76696BE 1162B5AA [root@master ~]# [root@master ~]# [root@master ~]# getcert request -f /etc/pki/tls/certs/test.example.com.cert -k /etc/pki/tls/private/test.example.com.key -c "Redwax Interop" -I test.example.com -D test.example.com -G rsa -g 2048 -u digitalSignature -u keyEncipherment -L challenge New signing request "test.example.com" added. [root@master ~]# getcert list -i test.example.com Number of certificates and requests being tracked: 10. Request ID 'test.example.com': status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/pki/tls/private/test.example.com.key' certificate: type=FILE,location='/etc/pki/tls/certs/test.example.com.cert' signing request thumbprint (MD5): 74A05277 98023D78 D0347B2B 187BAEB3 signing request thumbprint (SHA1): 32210467 F4BA9963 EEE64D92 4D33B7E0 1200316E CA: Redwax Interop issuer: O=Redwax Project,CN=Redwax Interop Testing Root Certificate Authority 2040 subject: CN=master.testrelm.test expires: 2020-06-27 05:07:21 EDT key usage: digitalSignature,nonRepudiation,keyEncipherment eku: id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Based on above observations, marking the bug as verified. Quick ping on progress - once this is released, we (Redwax) want to publish an interoperability guide for RHEL, but can't do that till this bugfix is released. Is there any news? The fixes are in the RHEL 8.3.0 beta, https://access.redhat.com/products/red-hat-enterprise-linux/beta Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (certmonger bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4671 |
Description of problem: The man page for getcert-add-scep-ca does not match implementation. Version-Release number of selected component (if applicable): certmonger 0.79.7-3.el8 How reproducible: Always Actual results: The -R option is documented as follows: -R ca-certificate-file The location of a PEM-formatted copy of the SCEP server's CA's certificate. A discovered value is supplied by the certmonger daemon for use in verifying the signature on data returned by the SCEP server, but it is not used for verifying HTTPS server certificates. This option must be specified if the URL is an https location. - "The location of a PEM-formatted copy of the SCEP server's CA's certificate" could refer to one of two certificates, either the CA certificate as returned by the GetCaCert call, or the CA certificate of the https connection to the SCEP server. - "A discovered value is supplied by the certmonger daemon for use in verifying the signature on data returned by the SCEP server, but it is not used for verifying HTTPS server certificates." - while technically true, what isn't mentioned is that any attempt to set the CA certificate of the https connection to the SCEP server will cause this certificate to override the discovered value, causing the CA certificate of the https connection to the SCEP server to be used to verify the PKCS7 responses. Chaos ensues. - "This option must be specified if the URL is an https location." - this option, if set, allows https, but breaks SCEP. This might be working by accident if the CA that is issuing the certificate is coincidentally also the CA that is hosting the SCEP server. Expected results: To fix the -R option, create a new dedicated option to pass the CA certificate of the https connection to the SCEP server that is completely separate from -R. Document and implement this separate option. Additional info: