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.

https://pagure.io/certmonger/pull-request/146

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