Created attachment 1737669 [details]
Intermediate

Created attachment 1737670 [details]
root ca

Further update to this - I've checked other virtual hosts i had to put on and the follow intermediates fail:


        Issuer: C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
        Validity
            Not Before: Feb 20 10:00:00 2014 GMT
            Not After : Feb 20 10:00:00 2024 GMT
        Subject: C = BE, O = GlobalSign nv-sa, CN = GlobalSign Domain Validation CA - SHA256 - G2


         Signature Algorithm: sha256WithRSAEncryption
        Issuer: OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
        Validity
            Not Before: Nov 21 00:00:00 2018 GMT
            Not After : Nov 21 00:00:00 2028 GMT
        Subject: C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
        Subject Public Key Info:

        Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
        Validity
            Not Before: Mar  8 12:00:00 2013 GMT
            Not After : Mar  8 12:00:00 2023 GMT
        Subject: C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA

I though maybe it was an issue with root ca, but i think this rules it out.


This one works fine - I can't for the life of me figure out why 

        Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
        Validity
            Not Before: Nov  6 12:23:52 2017 GMT
            Not After : Nov  6 12:23:52 2027 GMT
        Subject: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA CA 2018

I've managed to fix this issue.

At build time we run this to apply the pci-dss profile:

oscap xccdf eval --remediate --fetch-remote-resources --profile pci-dss --report /root/oscap_usgcb_remediation_report.html /usr/share/xml/scap/ssg/content/ssg-rhel8-xccdf.xml

This performs the following remediation which adds a new include into /etc/pki/tls/openssl.cnf:

[ default_modules ]

ssl_conf = ssl_module

[ ssl_module ]

system_default = crypto_policy

[ crypto_policy ]

.include /etc/crypto-policies/back-ends/openssl.config


.include /etc/crypto-policies/back-ends/opensslcnf.config

This is the added line:

.include /etc/crypto-policies/back-ends/openssl.config

which links to :

/etc/crypto-policies/back-ends/openssl.config -> /usr/share/crypto-policies/DEFAULT/openssl.txt


The other include link links to:

/etc/crypto-policies/back-ends/opensslcnf.config -> /usr/share/crypto-policies/DEFAULT/opensslcnf.txt



The Broken addition:

 cat /usr/share/crypto-policies/DEFAULT/openssl.txt
@SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8

the other file:

 cat /usr/share/crypto-policies/DEFAULT/opensslcnf.txt
CipherString = @SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256
MinProtocol = TLSv1.2
MaxProtocol = TLSv1.3
SignatureAlgorithms = ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_rsae_sha256:rsa_pss_pss_sha384:rsa_pss_rsae_sha384:rsa_pss_pss_sha512:rsa_pss_rsae_sha512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1


I'm guessing either openssl doesn't like the two includes or the broke addition breaks openssl, but in turn that breaks mod_ssl.

Not sure where to report this if i'm honest.

Thanks,

Adding OpenSSL and scap-security-guide owners, not immediately obvious how to triage this.

I'm assuming that the OpenSSL profile applied excludes the signature algorithm used by one of the CAs, but mod_ssl is not reporting enough information to be sure, which itself is a bug we can look at.  Not sure if that configuration is intentional or not, so maybe scap or OpenSSL folks can help?

As the end user, a log entry would have been useful from mod_ssl to say it was rejected because of reasons.

That said, i haven't looked at what the scap configuration has done yet and figured out what it didn't like about the certificate.

Yeah, agreed.  Could you file a support ticket for this please so we can investigate further?

I would but I can't unfortunately where on a self support tier :(

Happy to provide anything you need though if you get someone to contact me.

Thanks,

Fixed upstream: http://svn.apache.org/viewvc?view=revision&revision=1884452

@vpolasek The addition of .include /etc/crypto-policies/back-ends/openssl.config is totally wrong. The openssl.config is not supposed to be included, only the opensslcnf.config is.

The weak signature algorithms in certificates can be blocked by both the @SECLEVEL=2 or the signaturealgorithms setting.

However unless the broken include of the openssl.config somehow messes things up I do not see any reason why this certificate chain would not be acceptable for the settings in the opensslcnf.config.

Can you please try
openssl verify -auth_level 2 -CAfile <(cat rfd-ca.crt rfd-intermediate.crt) rccstatus.crt

There is also a possible spurious failure in this code path due to mod_ssl not clearing the OpenSSL error stack, if mod_md is also in use here.

https://bz.apache.org/bugzilla/show_bug.cgi?id=62880

Yeah, that is the most probable culprit - and the incorrect include triggers this.

I checked the certificates for you - They came back as okay on Auth 2

 openssl verify -auth_level 2 -CAfile <(cat rfd-ca.crt rfd-intermediate.crt) rccstatus.crt
rccstatus.crt: OK

So yeah, the broken include (which would be otherwise just ignored) triggers the issue from the comment #13.

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 (Moderate: httpd:2.4 security, 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/RHSA-2021:4257