To reproduce:

Just installing and starting certmonger will generate a local CA. It is placed as a PKCS#12 file in /var/lib/certmonger/local/creds

You can pull the CA certificate out of the PKCS#12 file with:

# openssl pkcs12 -in /var/lib/certmonger/local/creds -out /tmp/ca.pem -nokeys -nodes -passin pass:''

To examine the certificate:

edit the file to drop the prefix before -----BEGIN CERTIFICATE----- to avoid an offset error.

# openssl asn1parse -in /tmp/ca.pem -inform pem

An non-working CA certificate will look like:

[ snip ]

  542:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
  547:d=5  hl=2 l=   1 prim: BOOLEAN           :1
  550:d=5  hl=2 l=   5 prim: OCTET STRING      [HEX DUMP]:3003010101

This is an improperly encoded DER boolean value. It should look like:

  542:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
  547:d=5  hl=2 l=   1 prim: BOOLEAN           :255
  550:d=5  hl=2 l=   5 prim: OCTET STRING      [HEX DUMP]:30030101FF

To confirm that it works with Firefox generate a certificate using certmonger:

# getcert request -c local -f /etc/pki/tls/certs/local.crt -k /etc/pki/tls/private/local.key -U id-kp-clientAuth -U id-kp-serverAuth -u digitalSignature -u nonRepudiation -u keyEncipherment -u dataEncipherment

Install httpd and mod_ssl

Configure mod_ssl to use this certificate:

SSLCertificateFile /etc/pki/tls/certs/local.crt
SSLCertificateKeyFile /etc/pki/tls/private/local.key

Add the CA to the global trust:

# cp /tmp/ca.pem /etc/pki/ca-trust/source/anchors/cm-local-ca.pem
# update-ca-trust 

Restart httpd

Launch firefox and hit the host on port 443.

This bug can prevent a successful installation of RHOSP in some situations when enabling TLS for undercloud endpoints. The installation will appear to succeed but the resulting web UI is unavailable due to invalid DER encoding in the CA certificate.

Not sure what's happening with release flags ?!?!?

All z-streams of openstack director have you upgrade to RHEL 7.5, so this bug might be invalid?

This is the 7.6 BZ for the issue to prevent regressions. Either way it is still a valid bug for other consumers of certmonger.

Certmonger version: certmonger-0.78.4-8.el7.x86_64


Verified the bug on the basis of following observations:

1. Setup RHEL 7.6  system. (Note: Plain RHEl system without IPA server configurred)

# ipactl status
-bash: ipactl: command not found

 
2. Check for certmonger package version (in my case ccertmonger-0.78.4-8.el7.x86_64)

3. Pull the CA certificate out of the PKCS#12 file with:

# ls -l /var/lib/certmonger/local/creds (checking if file exists)
# openssl pkcs12 -in /var/lib/certmonger/local/creds -out /tmp/ca.pem -nokeys -nodes -passin pass:''

4. Edit the file /tmp/ca.pem created in above step to drop the prefix before -----BEGIN CERTIFICATE----- to avoid an offset error.

# openssl asn1parse -in /tmp/ca.pem -inform pem

5. Noticed the HEX dump as below:
  
  543:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
  548:d=5  hl=2 l=   1 prim: BOOLEAN           :255
  551:d=5  hl=2 l=   5 prim: OCTET STRING      [HEX DUMP]:30030101FF


6. Confirm that it works with Firefox generate a certificate using certmonger:

# getcert request -c local -f /etc/pki/tls/certs/local.crt -k /etc/pki/tls/private/local.key -U id-kp-clientAuth -U id-kp-serverAuth -u digitalSignature -u nonRepudiation -u keyEncipherment -u dataEncipherment

7. Install httpd and mod_ssl ( yum -y httpd; yum -y install mod_ssl)

Configure mod_ssl to use this certificate:

# vi /etc/httpd/conf.d/ssl.conf

SSLCertificateFile /etc/pki/tls/certs/local.crt
SSLCertificateKeyFile /etc/pki/tls/private/local.key

Add the CA to the global trust:

# cp /tmp/ca.pem /etc/pki/ca-trust/source/anchors/cm-local-ca.pem
# update-ca-trust 

8. Restart httpd, systemctl restart httpd

9. Launch firefox ( in my case Firefox version 60.0 (64-bit)) and hit the host on port 443.

URL : https://<IP_addr_plain_RHEL76_system>

In my case , it Returned with apache page upon accepting certificate.

Thus on the basis of above observations, marking the status of bug to "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, 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-2018:3018