Bug 1808052
| Summary: | Message failed verification: error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer certificate not found | ||
|---|---|---|---|
| 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 | Flags: | pm-rhel:
mirror+
|
| 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 | ||
|
Description
Graham Leggett
2020-02-27 17:29:00 UTC
Can you try re-creating the SCEP CA and add -I /etc/pki/interop/ca-cert.pem That worked, and I'm trying to work out why. Taking your advice, the CA was created like this: [root@bob ~]# getcert add-scep-ca -c "Redwax Interop" -u http://interop.redwax.eu/test/simple/scep -R /etc/pki/interop/ca-cert.pem -r /etc/pki/interop/ra-cert.pem -I /etc/pki/interop/ca-cert.pem -v -v -v and the request like this: [root@bob ~]# getcert request -f /etc/pki/interop/test.example.com.cert -k /etc/pki/interop/test.example.com.key -c "Redwax Interop" -I test.example.com -D test.example.com -G rsa -g 4096 -u digitalSignature -u keyEncipherment -L challenge Resulting in a certificate like this: [root@bob ~]# getcert list Number of certificates and requests being tracked: 1. Request ID 'test.example.com': status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/pki/interop/test.example.com.key' certificate: type=FILE,location='/etc/pki/interop/test.example.com.cert' signing request thumbprint (MD5): 29311BB1 B8130762 191CF677 1EE7C10A signing request thumbprint (SHA1): 79EF9367 32A65CD5 432EDD20 05E24E65 7F2DECB4 CA: Redwax Interop issuer: O=Redwax Project,CN=Redwax Interop Testing Root Certificate Authority 2040 subject: CN=bob.sharp.fm expires: 2020-02-29 17:40:51 GMT key usage: digitalSignature,nonRepudiation,keyEncipherment eku: id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Looking at man getcert-add-scep-ca, there is this: -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. This confuses me - "for use in verifying the signature on data returned by the SCEP server" - what is this certificate used for, if not this? There is also this in the man page: -I other-certificates-file The location of a file containing other PEM-formatted certificates which may be needed in order to properly verify signed responses sent by the SCEP server back to the client. Also confuses me - in reality this is the CA certificate that issued the RA certificate that signed the PKCS7 messages? The docs imply this would be intermediate certificates, not the CA certificate. Would it be possible to confirm if the code is wrong, or the docs are wrong? To sum up, the automatic setup querying the scep server for the CA and RA server doesn't work, instead you have to set the CA certificate manually as an "other certificate": getcert add-scep-ca -c "Redwax Interop" -u http://interop.redwax.eu/test/simple/scep -v -v -v The workaround as above is this: getcert add-scep-ca -c "Redwax Interop" -u http://interop.redwax.eu/test/simple/scep -I /etc/pki/interop/ca-cert.pem -v -v -v I noticed that the PKCS#7 file was signed by the CA (educated guess based on subject). -I specifies other certificates that can be used to verify the PKCS#7 response. The -R version of the CA is only used for TLS validation for the case where the URI is secured. I think the query worked in that it perhaps returned the right certs (I have no idea how to verify in your case) but the SCEP server is signing the response with the CA cert rather than the RA cert. And sadly until I get the upstream PR https://pagure.io/certmonger/pull-request/145 merged the -v will all be silently dropped. Just checked from the bottom up to be 100% sure, as openssl doesn't have a way to verify a signature on a PKCS7 that doesn't also want a lot of smime headers.
Config is:
<Location /test/simple/scep>
Require all granted
SetHandler scep
ScepRACertificate /etc/pki/interop/scep-ra.cert
ScepRAKey /etc/pki/interop/private/scep-ra.key
ScepSubjectRequest O
ScepSubjectRequest CN
ScepSubjectRequest C
ScepSubjectAltNameRequest rfc822Name
</Location>
The RA certificate looks like this, and has the issuer and serial number that is in the PKCS7 signature:
[root@coconut ~]# openssl x509 -text -in /etc/pki/interop/scep-ra.cert
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 6 (0x6)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = Redwax Interop Testing Root Certificate Authority 2040, O = Redwax Project
Validity
Not Before: Feb 15 20:53:52 2020 GMT
Not After : Feb 10 20:53:52 2040 GMT
Subject: C = NL, ST = Zuid-Holland, L = Leiden, O = SCEP, CN = Redwax Interop Test SCEP RA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
00:e9:76:a4:b7:8e:c0:0e:8c:39:6d:93:a4:3c:67:
46:92:9a:06:c3:f9:fe:f3:30:67:61:44:15:27:b7:
68:60:ac:7c:cd:e6:72:3c:f0:50:69:6a:31:42:0d:
91:81:84:d5:31:e4:6f:07:26:ef:62:1c:bf:11:65:
68:a2:c0:4b:63:b3:7b:6a:4d:d2:00:20:33:4c:c5:
24:31:cb:9e:26:ac:57:b6:22:fe:69:52:ec:26:0f:
9b:83:03:b3:7d:4c:0c:49:00:5d:93:d4:23:5c:a9:
a4:fe:d2:45:dc:fe:ce:cb:97:ac:24:6b:bd:4a:0e:
23:b6:07:e8:34:a8:82:aa:f7:7b:97:f8:84:f7:ac:
9f:f9:53:73:46:cc:e7:ac:e7:75:25:62:d5:71:9e:
b7:4b:dc:3e:fe:22:aa:fe:75:18:d6:0c:06:f4:14:
7c:4c:8c:97:08:71:f9:51:82:d9:a4:5f:18:ce:c9:
42:e3:86:81:92:7c:70:8d:aa:fe:e7:33:78:f0:93:
d5:77:2c:1f:7b:a2:6a:69:0d:5a:36:16:8d:73:d4:
36:f4:7e:6e:bb:5e:e4:a0:08:21:bf:c8:41:8d:c9:
f5:fa:00:af:e8:16:a5:da:d5:19:6d:7e:3c:de:24:
b6:79:62:03:88:1b:39:2a:b6:a3:d7:f9:c2:35:fa:
a7:78:41:25:8b:69:28:23:68:8f:ff:10:da:3d:3b:
9a:ec:77:37:b2:66:b7:a4:37:4b:4e:a2:ed:b5:9c:
59:1c:76:cd:9f:53:fc:f9:35:39:a1:96:0f:2b:2f:
a9:02:6c:1b:64:ea:7b:f4:cf:05:76:02:de:92:97:
ab:c4:1b:18:96:18:fd:f9:af:5a:26:46:60:89:4b:
ff:a7:78:d4:a6:6c:32:7d:f0:54:d0:7a:7c:52:c6:
a7:ca:c9:1d:3c:78:1e:f6:25:fd:75:cc:83:35:54:
71:5e:c6:84:5a:74:0d:bb:dd:e5:ee:7d:e9:9e:f8:
74:1a:18:55:51:ab:61:e1:bb:ee:73:af:d0:f1:73:
9d:ce:2b:cd:b6:b5:72:1c:c5:19:37:31:60:bb:91:
56:8e:22:a9:69:70:55:57:7d:73:5e:b4:d8:cf:93:
86:7d:2e:7e:0e:de:5e:42:af:78:71:ee:5b:fb:ad:
d6:ae:7d:18:f7:40:a4:63:06:47:cb:ba:0e:61:1d:
a8:87:26:2f:14:4e:76:c9:ad:b2:20:75:17:f7:bc:
e4:d2:31:e8:f8:71:a7:71:ad:84:3e:b6:d9:18:5a:
b0:3a:6b:85:10:4a:e9:a9:fe:aa:48:76:6b:8e:31:
ad:d0:26:56:3f:f3:a8:0a:a0:78:69:43:ed:02:0a:
63:e7:c9
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Subject Key Identifier:
2C:14:AC:3D:6D:3B:A4:1F:F8:2A:36:2D:CE:F1:16:65:57:C0:FA:63
X509v3 Authority Key Identifier:
keyid:ED:75:DE:35:14:3C:47:23:F1:B1:1A:E4:13:43:8C:BB:CC:C2:2B:56
DirName:/CN=Redwax Interop Testing Root Certificate Authority 2040/O=Redwax Project
serial:6F:11:B7:D8:55:D2:7D:9A:14:F3:B6:E9:15:2B:60:CA:8C:4B:E2:AA
Signature Algorithm: sha256WithRSAEncryption
7e:fd:9f:71:a5:d5:50:f0:a0:f5:da:c6:32:31:cb:f1:de:3e:
d8:79:1e:20:d4:f7:a9:c5:6f:fc:c2:47:cd:f1:ba:bf:92:ab:
1a:57:f8:85:da:cb:54:f6:28:59:d9:8d:ee:0c:02:66:39:78:
f7:03:99:79:f1:25:67:d6:ca:4c:60:32:c2:82:25:ab:02:c1:
91:ea:59:ad:e3:0e:28:91:c1:91:69:37:87:42:b3:8e:7d:7c:
01:09:cd:11:34:32:34:11:b5:98:47:ab:8e:9f:5e:40:5d:03:
a1:ac:ed:cf:42:ff:34:0c:5c:e5:ac:f3:97:3e:7d:3f:45:5f:
48:95:b1:af:69:f2:ba:f5:5a:98:65:a1:93:ad:df:a2:1e:47:
ad:3d:42:d8:b0:02:7a:bb:44:f8:b6:b9:39:e7:a3:36:f9:1b:
9c:ca:86:8f:b7:2a:71:17:46:ab:bd:76:d7:31:4c:63:84:c4:
b2:08:41:58:8b:d9:e2:0d:1d:5a:fa:23:79:7f:02:52:bd:b5:
1c:5a:e3:fb:c0:88:a1:5f:2f:72:18:39:7b:a7:c1:22:3c:da:
34:9f:91:bf:e7:df:3b:92:21:85:9d:cc:34:eb:93:66:ae:d6:
5e:0d:29:42:5f:30:ab:e6:2b:27:4f:53:bb:d0:4f:e1:eb:ef:
a2:84:9f:aa
-----BEGIN CERTIFICATE-----
MIIFFzCCA/+gAwIBAgIBBjANBgkqhkiG9w0BAQsFADBaMT8wPQYDVQQDEzZSZWR3
YXggSW50ZXJvcCBUZXN0aW5nIFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IDIw
NDAxFzAVBgNVBAoTDlJlZHdheCBQcm9qZWN0MB4XDTIwMDIxNTIwNTM1MloXDTQw
MDIxMDIwNTM1MlowajELMAkGA1UEBhMCTkwxFTATBgNVBAgMDFp1aWQtSG9sbGFu
ZDEPMA0GA1UEBwwGTGVpZGVuMQ0wCwYDVQQKDARTQ0VQMSQwIgYDVQQDDBtSZWR3
YXggSW50ZXJvcCBUZXN0IFNDRVAgUkEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw
ggIKAoICAQDpdqS3jsAOjDltk6Q8Z0aSmgbD+f7zMGdhRBUnt2hgrHzN5nI88FBp
ajFCDZGBhNUx5G8HJu9iHL8RZWiiwEtjs3tqTdIAIDNMxSQxy54mrFe2Iv5pUuwm
D5uDA7N9TAxJAF2T1CNcqaT+0kXc/s7Ll6wka71KDiO2B+g0qIKq93uX+IT3rJ/5
U3NGzOes53UlYtVxnrdL3D7+Iqr+dRjWDAb0FHxMjJcIcflRgtmkXxjOyULjhoGS
fHCNqv7nM3jwk9V3LB97omppDVo2Fo1z1Db0fm67XuSgCCG/yEGNyfX6AK/oFqXa
1RltfjzeJLZ5YgOIGzkqtqPX+cI1+qd4QSWLaSgjaI//ENo9O5rsdzeyZrekN0tO
ou21nFkcds2fU/z5NTmhlg8rL6kCbBtk6nv0zwV2At6Sl6vEGxiWGP35r1omRmCJ
S/+neNSmbDJ98FTQenxSxqfKyR08eB72Jf11zIM1VHFexoRadA273eXufeme+HQa
GFVRq2Hhu+5zr9Dxc53OK822tXIcxRk3MWC7kVaOIqlpcFVXfXNetNjPk4Z9Ln4O
3l5Cr3hx7lv7rdaufRj3QKRjBkfLug5hHaiHJi8UTnbJrbIgdRf3vOTSMej4cadx
rYQ+ttkYWrA6a4UQSump/qpIdmuOMa3QJlY/86gKoHhpQ+0CCmPnyQIDAQABo4HX
MIHUMAwGA1UdEwEB/wQCMAAwCwYDVR0PBAQDAgWgMB0GA1UdDgQWBBQsFKw9bTuk
H/gqNi3O8RZlV8D6YzCBlwYDVR0jBIGPMIGMgBTtdd41FDxHI/GxGuQTQ4y7zMIr
VqFepFwwWjE/MD0GA1UEAxM2UmVkd2F4IEludGVyb3AgVGVzdGluZyBSb290IENl
cnRpZmljYXRlIEF1dGhvcml0eSAyMDQwMRcwFQYDVQQKEw5SZWR3YXggUHJvamVj
dIIUbxG32FXSfZoU87bpFStgyoxL4qowDQYJKoZIhvcNAQELBQADggEBAH79n3Gl
1VDwoPXaxjIxy/HePth5HiDU96nFb/zCR83xur+SqxpX+IXay1T2KFnZje4MAmY5
ePcDmXnxJWfWykxgMsKCJasCwZHqWa3jDiiRwZFpN4dCs459fAEJzRE0MjQRtZhH
q46fXkBdA6Gs7c9C/zQMXOWs85c+fT9FX0iVsa9p8rr1WphloZOt36IeR609Qtiw
Anq7RPi2uTnnozb5G5zKho+3KnEXRqu9dtcxTGOExLIIQViL2eINHVr6I3l/AlK9
tRxa4/vAiKFfL3IYOXunwSI82jSfkb/n3zuSIYWdzDTrk2au1l4NKUJfMKvmKydP
U7vQT+Hr76KEn6o=
-----END CERTIFICATE-----
Signing on the mod_scep side happens here:
https://source.redwax.eu/projects/RS/repos/mod_scep/browse/mod_scep.c#1612
RA cert is set here:
https://source.redwax.eu/projects/RS/repos/mod_scep/browse/mod_scep.c#335
from this directive:
https://source.redwax.eu/projects/RS/repos/mod_scep/browse/mod_scep.c#652
The scep GetCACert returns both the RA cert, and the CA cert that signed the RA cert, and these both appear in the certmonger config file:
id=Redwax Interop
ca_aka=SCEP (certmonger 0.79.7)
ca_is_default=0
ca_type=EXTERNAL
ca_external_helper=/usr/libexec/certmonger/scep-submit -u http://interop.redwax.eu/test/simple/scep -I /etc/pki/interop/ca-cert.pem
ca_capabilities=AES,POSTPKIOperation,SHA-1,SHA-256,SHA-512,SCEPStandard
ca_encryption_cert=-----BEGIN CERTIFICATE-----
MIIFFzCCA/+gAwIBAgIBBjANBgkqhkiG9w0BAQsFADBaMT8wPQYDVQQDEzZSZWR3
YXggSW50ZXJvcCBUZXN0aW5nIFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IDIw
NDAxFzAVBgNVBAoTDlJlZHdheCBQcm9qZWN0MB4XDTIwMDIxNTIwNTM1MloXDTQw
MDIxMDIwNTM1MlowajELMAkGA1UEBhMCTkwxFTATBgNVBAgMDFp1aWQtSG9sbGFu
ZDEPMA0GA1UEBwwGTGVpZGVuMQ0wCwYDVQQKDARTQ0VQMSQwIgYDVQQDDBtSZWR3
YXggSW50ZXJvcCBUZXN0IFNDRVAgUkEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw
ggIKAoICAQDpdqS3jsAOjDltk6Q8Z0aSmgbD+f7zMGdhRBUnt2hgrHzN5nI88FBp
ajFCDZGBhNUx5G8HJu9iHL8RZWiiwEtjs3tqTdIAIDNMxSQxy54mrFe2Iv5pUuwm
D5uDA7N9TAxJAF2T1CNcqaT+0kXc/s7Ll6wka71KDiO2B+g0qIKq93uX+IT3rJ/5
U3NGzOes53UlYtVxnrdL3D7+Iqr+dRjWDAb0FHxMjJcIcflRgtmkXxjOyULjhoGS
fHCNqv7nM3jwk9V3LB97omppDVo2Fo1z1Db0fm67XuSgCCG/yEGNyfX6AK/oFqXa
1RltfjzeJLZ5YgOIGzkqtqPX+cI1+qd4QSWLaSgjaI//ENo9O5rsdzeyZrekN0tO
ou21nFkcds2fU/z5NTmhlg8rL6kCbBtk6nv0zwV2At6Sl6vEGxiWGP35r1omRmCJ
S/+neNSmbDJ98FTQenxSxqfKyR08eB72Jf11zIM1VHFexoRadA273eXufeme+HQa
GFVRq2Hhu+5zr9Dxc53OK822tXIcxRk3MWC7kVaOIqlpcFVXfXNetNjPk4Z9Ln4O
3l5Cr3hx7lv7rdaufRj3QKRjBkfLug5hHaiHJi8UTnbJrbIgdRf3vOTSMej4cadx
rYQ+ttkYWrA6a4UQSump/qpIdmuOMa3QJlY/86gKoHhpQ+0CCmPnyQIDAQABo4HX
MIHUMAwGA1UdEwEB/wQCMAAwCwYDVR0PBAQDAgWgMB0GA1UdDgQWBBQsFKw9bTuk
H/gqNi3O8RZlV8D6YzCBlwYDVR0jBIGPMIGMgBTtdd41FDxHI/GxGuQTQ4y7zMIr
VqFepFwwWjE/MD0GA1UEAxM2UmVkd2F4IEludGVyb3AgVGVzdGluZyBSb290IENl
cnRpZmljYXRlIEF1dGhvcml0eSAyMDQwMRcwFQYDVQQKEw5SZWR3YXggUHJvamVj
dIIUbxG32FXSfZoU87bpFStgyoxL4qowDQYJKoZIhvcNAQELBQADggEBAH79n3Gl
1VDwoPXaxjIxy/HePth5HiDU96nFb/zCR83xur+SqxpX+IXay1T2KFnZje4MAmY5
ePcDmXnxJWfWykxgMsKCJasCwZHqWa3jDiiRwZFpN4dCs459fAEJzRE0MjQRtZhH
q46fXkBdA6Gs7c9C/zQMXOWs85c+fT9FX0iVsa9p8rr1WphloZOt36IeR609Qtiw
Anq7RPi2uTnnozb5G5zKho+3KnEXRqu9dtcxTGOExLIIQViL2eINHVr6I3l/AlK9
tRxa4/vAiKFfL3IYOXunwSI82jSfkb/n3zuSIYWdzDTrk2au1l4NKUJfMKvmKydP
U7vQT+Hr76KEn6o=
-----END CERTIFICATE-----
ca_encryption_issuer_cert=-----BEGIN CERTIFICATE-----
MIIEDTCCAvWgAwIBAgIUbxG32FXSfZoU87bpFStgyoxL4qowDQYJKoZIhvcNAQEF
BQAwWjE/MD0GA1UEAxM2UmVkd2F4IEludGVyb3AgVGVzdGluZyBSb290IENlcnRp
ZmljYXRlIEF1dGhvcml0eSAyMDQwMRcwFQYDVQQKEw5SZWR3YXggUHJvamVjdDAe
Fw0yMDAyMTExNjM4NTZaFw00MDAyMDYxNjM4NTZaMFoxPzA9BgNVBAMTNlJlZHdh
eCBJbnRlcm9wIFRlc3RpbmcgUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkgMjA0
MDEXMBUGA1UEChMOUmVkd2F4IFByb2plY3QwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDnICcjGF9EcH0kRu9TgqiXAV+YdBUOjV4jG9wCbJdZMv6tGYWY
IPszrK3Cmw49uMbMgAEL/hB2mr/gZIFMQ0rs2GWwkaKolvg0rw9gE8PwR2p6jthu
L+CzocyHkc27f/UGhekYSnbcgIitFNseaJWEI/d+eF8LPkPXhsSUVkCF/wcEG2xM
DgS1KckoF7EJ9Tsc7XRVQ3Doq5WL+NCCnuSmeMcVTGhI9XaGreu+DYYmCR3vnDXa
vx67A45vlYcgJU4pDL/oMwJW+WKiwKjpiZm4kyRZWYHGLlCUb+ckedhM1eCZwwsg
yJKm0aPJbTDjlqRBshU++4aZMV2AFdLRIVq7AgMBAAGjgcowgccwHQYDVR0OBBYE
FO113jUUPEcj8bEa5BNDjLvMwitWMIGXBgNVHSMEgY8wgYyAFO113jUUPEcj8bEa
5BNDjLvMwitWoV6kXDBaMT8wPQYDVQQDEzZSZWR3YXggSW50ZXJvcCBUZXN0aW5n
IFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IDIwNDAxFzAVBgNVBAoTDlJlZHdh
eCBQcm9qZWN0ghRvEbfYVdJ9mhTztukVK2DKjEviqjAMBgNVHRMEBTADAQH/MA0G
CSqGSIb3DQEBBQUAA4IBAQDONOZcaEB3HjLi4wCkeSucGgmDyC2bwPIvZojr9UOx
45FyB5awhRgUP/pKwZIDJ7y5b1Gd20AKjkac3kiXETTjCvGSm3v9EKtKclykd3Jd
oKK1WupKhQxoTb6qTakwahxf9nggsjt0u+G9ngnHJiIRdejP8TIAtxZVKAn1Riw7
OdNWzrNdq9E/4Ysr9m5jEYBlZKHLAkyvltjQfet9fsMCG7Ty9kxYVX7AszTEBkeH
4Zd5gubTX2phjMbQk+uzHtoAQF4E5mwrhNjuMn6q2COB+M254u/pGQsi3i1LMxBD
ch5AKvxjPsO3pLFi1oWvkJNArKw3DJLcTnCQl7Wn4ZzR
-----END CERTIFICATE-----
Using the following patch to print out the certs from the environment as they come in:
--- src/scep.c-orig 2020-02-28 22:54:43.151569846 +0000
+++ src/scep.c 2020-02-28 22:58:07.725289195 +0000
@@ -307,6 +307,10 @@
else
cm_log_set_method(cm_log_syslog);
+ cm_log(0, "RA: %s", racert);
+ cm_log(0, "CA: %s", cacert);
+ cm_log(0, "Cert: %s", certs);
+
pctx = poptGetContext(argv[0], argc, argv, popts, 0);
if (pctx == NULL) {
return CM_SUBMIT_STATUS_UNCONFIGURED;
and removing the -I, we get this:
Feb 28 23:16:51 bob scep-submit[16536]: RA: -----BEGIN CERTIFICATE-----#012MIIFFzCCA/+gAwIBAgIBBjANBgkqhkiG9w0BAQsFADBaMT8wPQYDVQQDEzZSZWR3#012YXggSW50ZXJvcCBUZXN0aW5nIFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IDIw#012NDAxFzAVBgNVBAoTDlJlZHdheCBQcm9qZWN0MB4XDTIwMDIxNTIwNTM1MloXDTQw#012MDIxMDIwNTM1MlowajELMAkGA1UEBhMCTkwxFTATBgNVBAgMDFp1aWQtSG9sbGFu#012ZDEPMA0GA1UEBwwGTGVpZGVuMQ0wCwYDVQQKDARTQ0VQMSQwIgYDVQQDDBtSZWR3#012YXggSW50ZXJvcCBUZXN0IFNDRVAgUkEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw#012ggIKAoICAQDpdqS3jsAOjDltk6Q8Z0aSmgbD+f7zMGdhRBUnt2hgrHzN5nI88FBp#012ajFCDZGBhNUx5G8HJu9iHL8RZWiiwEtjs3tqTdIAIDNMxSQxy54mrFe2Iv5pUuwm#012D5uDA7N9TAxJAF2T1CNcqaT+0kXc/s7Ll6wka71KDiO2B+g0qIKq93uX+IT3rJ/5#012U3NGzOes53UlYtVxnrdL3D7+Iqr+dRjWDAb0FHxMjJcIcflRgtmkXxjOyULjhoGS#012fHCNqv7nM3jwk9V3LB97omppDVo2Fo1z1Db0fm67XuSgCCG/yEGNyfX6AK/oFqXa#0121RltfjzeJLZ5YgOIGzkqtqPX+cI1+qd4QSWLaSgjaI//ENo9O5rsdzeyZrekN0tO#012ou21nFkcds2fU/z5NTmhlg8rL6kCbBtk6nv0zwV2At6Sl6vEGxiWGP35r1omRmCJ#012S/+neNSmbDJ98FTQenxSxqfKyR08eB72Jf11zIM1VHFexoRadA273eXufeme+HQa#012GFVRq2Hhu+5zr9Dxc53OK822tXIcxRk3MWC7kVaOIqlpcFVXfXNetNjPk4Z9Ln4O#0123l5Cr3hx7lv7rdaufRj3QKRjBkfLug5hHaiHJi8UTnbJrbIgdRf3vOTSMej4cadx#012rYQ+ttkYWrA6a4UQSump/qpIdmuOMa3QJlY/86gKoHhpQ+0CCmPnyQIDAQABo4HX#012MIHUMAwGA1UdEwEB/wQCMAAwCwYDVR0PBAQDAgWgMB0GA1UdDgQWBBQsFKw9bTuk#012H/gqNi3O8RZlV8D6YzCBlwYDVR0jBIGPMIGMgBTtdd41FDxHI/GxGuQTQ4y7zMIr#012VqFepFwwWjE/MD0GA1UEAxM2UmVkd2F4IEludGVyb3AgVGVzdGluZyBSb290IENl#012cnRpZmljYXRlIEF1dGhvcml0eSAyMDQwMRcwFQYDVQQKEw5SZWR3YXggUHJvamVj#012dIIUbxG32FXSfZoU87bpFStgyoxL4qowDQYJKoZIhvcNAQELBQADggEBAH79n3Gl#0121VDwoPXaxjIxy/HePth5HiDU96nFb/zCR83xur+SqxpX+IXay1T2KFnZje4MAmY5#012ePcDmXnxJWfWykxgMsKCJasCwZHqWa3jDiiRwZFpN4dCs459fAEJzRE0MjQRtZhH#012q46fXkBdA6Gs7c9C/zQMXOWs85c+fT9FX0iVsa9p8rr1WphloZOt36IeR609Qtiw#012Anq7RPi2uTnnozb5G5zKho+3KnEXRqu9dtcxTGOExLIIQViL2eINHVr6I3l/AlK9#012tRxa4/vAiKFfL3IYOXunwSI82jSfkb/n3zuSIYWdzDTrk2au1l4NKUJfMKvmKydP#012U7vQT+Hr76KEn6o=#012-----END CERTIFICATE-----
Feb 28 23:16:51 bob scep-submit[16536]: CA: -----BEGIN CERTIFICATE-----#012MIIEDTCCAvWgAwIBAgIUbxG32FXSfZoU87bpFStgyoxL4qowDQYJKoZIhvcNAQEF#012BQAwWjE/MD0GA1UEAxM2UmVkd2F4IEludGVyb3AgVGVzdGluZyBSb290IENlcnRp#012ZmljYXRlIEF1dGhvcml0eSAyMDQwMRcwFQYDVQQKEw5SZWR3YXggUHJvamVjdDAe#012Fw0yMDAyMTExNjM4NTZaFw00MDAyMDYxNjM4NTZaMFoxPzA9BgNVBAMTNlJlZHdh#012eCBJbnRlcm9wIFRlc3RpbmcgUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkgMjA0#012MDEXMBUGA1UEChMOUmVkd2F4IFByb2plY3QwggEiMA0GCSqGSIb3DQEBAQUAA4IB#012DwAwggEKAoIBAQDnICcjGF9EcH0kRu9TgqiXAV+YdBUOjV4jG9wCbJdZMv6tGYWY#012IPszrK3Cmw49uMbMgAEL/hB2mr/gZIFMQ0rs2GWwkaKolvg0rw9gE8PwR2p6jthu#012L+CzocyHkc27f/UGhekYSnbcgIitFNseaJWEI/d+eF8LPkPXhsSUVkCF/wcEG2xM#012DgS1KckoF7EJ9Tsc7XRVQ3Doq5WL+NCCnuSmeMcVTGhI9XaGreu+DYYmCR3vnDXa#012vx67A45vlYcgJU4pDL/oMwJW+WKiwKjpiZm4kyRZWYHGLlCUb+ckedhM1eCZwwsg#012yJKm0aPJbTDjlqRBshU++4aZMV2AFdLRIVq7AgMBAAGjgcowgccwHQYDVR0OBBYE#012FO113jUUPEcj8bEa5BNDjLvMwitWMIGXBgNVHSMEgY8wgYyAFO113jUUPEcj8bEa#0125BNDjLvMwitWoV6kXDBaMT8wPQYDVQQDEzZSZWR3YXggSW50ZXJvcCBUZXN0aW5n#012IFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IDIwNDAxFzAVBgNVBAoTDlJlZHdh#012eCBQcm9qZWN0ghRvEbfYVdJ9mhTztukVK2DKjEviqjAMBgNVHRMEBTADAQH/MA0G#012CSqGSIb3DQEBBQUAA4IBAQDONOZcaEB3HjLi4wCkeSucGgmDyC2bwPIvZojr9UOx#01245FyB5awhRgUP/pKwZIDJ7y5b1Gd20AKjkac3kiXETTjCvGSm3v9EKtKclykd3Jd#012oKK1WupKhQxoTb6qTakwahxf9nggsjt0u+G9ngnHJiIRdejP8TIAtxZVKAn1Riw7#012OdNWzrNdq9E/4Ysr9m5jEYBlZKHLAkyvltjQfet9fsMCG7Ty9kxYVX7AszTEBkeH#0124Zd5gubTX2phjMbQk+uzHtoAQF4E5mwrhNjuMn6q2COB+M254u/pGQsi3i1LMxBD#012ch5AKvxjPsO3pLFi1oWvkJNArKw3DJLcTnCQl7Wn4ZzR#012-----END CERTIFICATE-----
Feb 28 23:16:51 bob scep-submit[16536]: Cert: (null)
Feb 28 23:16:51 bob scep-submit[16536]: Checking server capabilities list for "Renewal"
Feb 28 23:16:51 bob scep-submit[16536]: found it.
Feb 28 23:16:52 bob scep-submit[16536]: Message failed verification.
Feb 28 23:16:52 bob scep-submit[16536]: error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer certificate not found
Feb 28 23:16:52 bob scep-submit[16536]: Error: failed to verify signature on server response.
The CA cert has arrived inside scep.c, but is being ignored...
...this code is strange: https://pagure.io/certmonger/blob/master/f/src/scep.c#_888 memset(&cacerts, 0, sizeof(cacerts)); cacerts[0] = cacert ? cacert : racert; cacerts[1] = cacert ? racert : NULL; cacerts[2] = NULL; Typically a certificate chain needs to be the leaf certificate first, then the intermediates, then lastly the CA certificates. In the above code the CA cert comes first, then the RA cert, and then the intermediates come after, which is the wrong order. In theory, this is the correct order: --- src/scep.c-orig 2020-02-29 00:11:34.217139348 +0000 +++ src/scep.c 2020-02-29 00:15:56.931780124 +0000 @@ -895,8 +895,8 @@ if ((content_type2 != NULL) && (strcasecmp(content_type2, "application/x-pki-message") == 0)) { memset(&cacerts, 0, sizeof(cacerts)); - cacerts[0] = cacert ? cacert : racert; - cacerts[1] = cacert ? racert : NULL; + cacerts[0] = racert ? racert : cacert; + cacerts[1] = racert ? cacert : NULL; cacerts[2] = NULL; racerts = NULL; if ((certs != NULL) && The above patch isn't enough, we have some more strange code here: https://pagure.io/certmonger/blob/master/f/src/scep.c#_891 After putting the cacert and racert in backwards order into cacerts, we now take the othercerts and put that into a variable called racerts. We then feed cacerts (containing the racert) and racerts (containing the othercert) and pass these to cm_pkcs7_verify_signed(). https://pagure.io/certmonger/blob/master/f/src/pkcs7.c#_889 In this code cacerts (containing the cacert and racert), now called roots, is put into a searchable X509_STORE, and racerts (containing the othercert that in the above workaround contained the cacert, but not the RA cert), now called othercerts, is added to the PKCS7 signer certificates. Then we try to verify. I am not seeing how to fix this without just rewriting the whole thing. I redid the certificate handling for op_get_cert_initial below, this allows certificates to be issued successfully both with and without the other certificates. The comment in the code explains what needs to be done. Variables are renamed to match the cm_pkcs7_parse() and cm_pkcs7_verify_signed() calls.
[minfrin@bob SPECS]$ cat ../SOURCES/0034-reorder-certs.patch
--- src/scep.c-orig 2020-02-29 17:47:21.865202443 +0000
+++ src/scep.c 2020-02-29 17:49:17.153040316 +0000
@@ -211,12 +211,12 @@
const char *mode = NULL, *content_type = NULL, *content_type2 = NULL;
void *ctx;
char *params = "", *params2 = NULL, *racert = NULL, *cacert = NULL;
- char **othercerts = NULL, *cert1 = NULL, *cert2 = NULL, *certs = NULL;
+ char **certothers = NULL, *certleaf = NULL, *certtop = NULL, *certs = NULL;
char **racertp, **cacertp, *dracert = NULL, *dcacert = NULL;
char buf[LINE_MAX] = "";
const unsigned char **buffers = NULL;
size_t n_buffers = 0, *lengths = NULL, j;
- const char *cacerts[3], **racerts;
+ const char *roots[3], **othercerts;
dbus_bool_t missing_args = FALSE;
char *sent_tx, *tx, *msgtype, *pkistatus, *failinfo, *s, *tmp1, *tmp2;
unsigned char *sent_nonce, *sender_nonce, *recipient_nonce, *payload;
@@ -858,27 +858,27 @@
n_buffers++;
}
if (cm_pkcs7_parsev(CM_PKCS7_LEAF_PREFER_ENCRYPT, ctx,
- racertp, cacertp, &othercerts,
+ racertp, cacertp, &certothers,
NULL, NULL,
n_buffers, buffers, lengths) == 0) {
if (racert != NULL) {
printf("%s", racert);
if (cacert != NULL) {
printf("%s", cacert);
- if (othercerts != NULL) {
+ if (certothers != NULL) {
for (c = 0;
- othercerts[c] != NULL;
+ certothers[c] != NULL;
c++) {
printf("%s",
- othercerts[c]);
+ certothers[c]);
}
}
if ((dracert != NULL) &&
- (cert_among(dracert, racert, cacert, othercerts) != 0)) {
+ (cert_among(dracert, racert, cacert, certothers) != 0)) {
printf("%s", dracert);
}
if ((dcacert != NULL) &&
- (cert_among(dcacert, racert, cacert, othercerts) != 0)) {
+ (cert_among(dcacert, racert, cacert, certothers) != 0)) {
printf("%s", dcacert);
}
}
@@ -894,47 +894,66 @@
case op_pkcsreq:
if ((content_type2 != NULL) && (strcasecmp(content_type2,
"application/x-pki-message") == 0)) {
- memset(&cacerts, 0, sizeof(cacerts));
- cacerts[0] = cacert ? cacert : racert;
- cacerts[1] = cacert ? racert : NULL;
- cacerts[2] = NULL;
- racerts = NULL;
+ /*
+ * At this point, we have:
+ * - zero or more ra certs; and
+ * - zero or more ca certificates; and
+ * - zero or more other certificates; that
+ * need to be reordered so that the leaf
+ * certificates go first, the ca certificates
+ * are separated into a seperate certificate
+ * store, and the other certificates go after
+ * the leaf certificates.
+ *
+ * To do this we put cacert into the ca store,
+ * the racert at the top of the othercerts list.
+ * Then we parse certs, placing all ca certs
+ * we find into the ca store, and all other
+ * certs we find after the racert.
+ *
+ * As a limitation of cm_pkcs7_parse(), we
+ * can only isolate one ca certificate in the
+ * list of other certificates.
+ */
+ /* handle the other certs */
if ((certs != NULL) &&
(cm_pkcs7_parse(0, ctx,
- &cert1, &cert2, &othercerts,
+ &certleaf, &certtop, &certothers,
NULL, NULL,
(const unsigned char *) certs,
strlen(certs), NULL) == 0)) {
+ roots[0] = cacert ? cacert : certtop ? certtop : NULL;
+ roots[1] = cacert ? certtop : NULL;
+ roots[2] = NULL;
for (c = 0;
- (othercerts != NULL) &&
- (othercerts[c] != NULL);
+ (certothers != NULL) &&
+ (certothers[c] != NULL);
c++) {
continue;
}
- racerts = talloc_array_ptrtype(ctx, racerts, c + 5);
- for (c = 0;
- (othercerts != NULL) &&
- (othercerts[c] != NULL);
- c++) {
- racerts[c] = othercerts[c];
- }
- if (cacert != NULL) {
- racerts[c++] = cacert;
- }
- if (cert1 != NULL) {
- racerts[c++] = cert1;
+ othercerts = talloc_array_ptrtype(ctx, othercerts, c + 3);
+ c = 0;
+ if (racert != NULL) {
+ othercerts[c++] = racert;
}
- if (cert2 != NULL) {
- racerts[c++] = cert2;
+ if (certleaf != NULL) {
+ othercerts[c++] = certleaf;
}
- if (racert != NULL) {
- racerts[c++] = racert;
+ while (certothers != NULL && *certothers != NULL) {
+ othercerts[c++] = *certothers++;
}
- racerts[c++] = NULL;
+ othercerts[c++] = NULL;
+ }
+ else {
+ roots[0] = cacert;
+ roots[1] = NULL;
+ othercerts = talloc_array_ptrtype(ctx, othercerts, 2);
+ othercerts[0] = racert ? racert : NULL;
+ othercerts[1] = NULL;
}
ERR_clear_error();
i = cm_pkcs7_verify_signed((unsigned char *) results2, results_length2,
- cacerts, racerts,
+ roots, othercerts,
NID_pkcs7_data, ctx, NULL,
&tx, &msgtype, &pkistatus, &failinfo,
&sender_nonce, &sender_nonce_length,
Thanks for the patch, I'll take a look. Thanks for this. Had a chance to look at this stage? Keen to see this fix backported so we can deploy private certs via SCEP. Not yet, sorry, and I can't really give an ETA. Can you attach a copy of the patch to the BZ? It'll make importing it officially a lot easier due to the tab use. Did you mean certtop instead of cacert here? roots[1] = cacert ? certtop : NULL; I think I'll need to document in getcert-add-scep-ca that if othercerts is provided them it should be a discrete set of certificates relevant to the PKI issuing the cert over SCEP given that cm_pkcs7_parse() can return only a single root cert (whichever one it finds first). So far this is looking good. Sort of thinking out loud here in case I need to refer back to it. In cm_pkcs7_parsev() a cert is considered a leaf if it didn't sign any others. And a leaf cannot be a top. So the output of a self-signed CA as othercerts will be certleaf and certtop will be NULL. For the IPA case, which typically has a self-signed CA, this causes what was arguably a workaround to break. IPA (dogtag) issues SCEP certs using its CA cert, not a special RA cert. So the workaround was to pass it in as othercerts which caused it to appear in both cacerts and racerts. To make IPA issue SCEP certs one would generally do something like: getcert add-scep-ca -c ipascep -u http://`hostname`:8080/ca/cgi-bin/pkiclient.exe -I /etc/ipa/ca.crt cm_pkcs7_parsev() evaluates with certleaf == cert, certtop = NULL. With this change roots will be all NULL and racerts will contain certleaf (twice). So we pass into PKCS7_verify(p7, NULL, store, ...). With nothing to verify against it blows up (I'm assuming). As a test I hardcoded it so that cert1 is set as roots[0] and the verification passed because racerts also gets the contents of othercerts. I'm thinking a special case is needed, I'm just not sure where to apply it yet. The corner case is that there is no separate RA agent detected from the SCEP CA, only ca_encryption_cert gets set (dogtag in the simplest case returns a single cert). The condition makes my head hurt. pseudo-ish code: if (cacert == NULL && racert == NULL && certtop == NULL && certleaf != NULL) { /* does this imply that othercerts != NULL? I guess so */ roots[0] == certleaf; } /* racerts is processed as-is and will pull in the lone cert in othercerts */ The result is that cacerts == racerts == IPA cert which both signed the PKCS#7 and itself. Fixed upstream in master: 71f5fbdbcddd464711a15d94e8c73cb598f837dd Yeah so it was resolv.conf. When I added nameserver in it, it worked. version: certmonger-0.79.7-14.el8.x86_64 [root@master ~]# getcert add-scep-ca -c "Redwax Interop" -u http://interop.redwax.eu/test/simple/scep 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 http://interop.redwax.eu/test/simple/scep 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/certs/test.example.com.key -c "Redwax Interop" -I test.example.com -D test.example.com -G rsa -g 4096 -u digitalSignature -u keyEncipherment -L challenge New signing request "test.example.com" added. [root@master ~]# [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/certs/test.example.com.key' certificate: type=FILE,location='/etc/pki/tls/certs/test.example.com.cert' signing request thumbprint (MD5): A84AC65E E2C8A642 16314AF6 6F547144 signing request thumbprint (SHA1): A826026B 05751F9E B7591865 5422B24A B595004F CA: Redwax Interop issuer: O=Redwax Project,CN=Redwax Interop Testing Root Certificate Authority 2040 subject: CN=master.testrelm.test expires: 2020-07-09 07:22:53 EDT key usage: digitalSignature,nonRepudiation,keyEncipherment eku: id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes The scep CA added and cert issued and in monitoring state. Hence marking the bug as verified. 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 |