All we really need is the PEM blob. You can paste that in as a comment in the issue.

If all you have is the DER version you can convert it to PEM:

$ openssl x509 -inform der -in /path/to/cert

Here's the PEM:

-----BEGIN CERTIFICATE-----
MIIF/zCCBOegAwIBAgICLiYwDQYJKoZIhvcNAQELBQAwWTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDENMAsGA1UECxMERlBLSTEhMB8GA1UEAxMYRmVkZXJhbCBDb21tb24gUG9saWN5IENBMB4XDTE1MDczMDEzMTg1MloXDTI1MDczMDEzMTI0MlowbjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VudHJ1c3QxIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxKTAnBgNVBAsTIEVudHJ1c3QgTWFuYWdlZCBTZXJ2aWNlcyBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmKijeijcOM2CyoIumDqIrsOiv/Xv25+w9oDZQEMT2bRr5r4cyDsdlHhw8IZhZIrzctn4CK/Of260HyoLpFoKXBEvQ5dhqXLJzlw0pvnALRiaxFevxHL+qPs9qptGETgzRGjBeADS5fx/ecn0eJeeGiPjF+q8c0507/o/0KbS92ciXvC50KHiB6+vSaNtXunpBkbZWCfS/K+ap+7P2xfSmf2pLFngdtXdcHIt3SCKTeWzPK+WJ0CxI484N+UrG6gRH7df0L4MQ2xFk1vfyCI+YVq6cgVXtt6ScDbRFpbrxcYc0M98SdFNWQUUF8klR28dJNEskZYYRb+q4nKKBE4bSQIDAQABo4ICujCCArYwDwYDVR0TAQH/BAUwAwEB/zCBiAYDVR0gBIGAMH4wDAYKYIZIAWUDAgEDBjAMBgpghkgBZQMCAQMHMAwGCmCGSAFlAwIBAwgwDAYKYIZIAWUDAgEDJDAMBgpghkgBZQMCAQMNMAwGCmCGSAFlAwIBAxEwDAYKYIZIAWUDAgEDJzAMBgpghkgBZQMCAQMoMAwGCmCGSAFlAwIBAykwTwYIKwYBBQUHAQEEQzBBMD8GCCsGAQUFBzAChjNodHRwOi8vaHR0cC5mcGtpLmdvdi9mY3BjYS9jYUNlcnRzSXNzdWVkVG9mY3BjYS5wN2MwggEeBggrBgEFBQcBCwSCARAwggEMME0GCCsGAQUFBzAFhkFodHRwOi8vcm9vdHdlYi5tYW5hZ2VkLmVudHJ1c3QuY29tL1NJQS9DZXJ0c0lzc3VlZEJ5RU1TUm9vdENBLnA3YzCBugYIKwYBBQUHMAWGga1sZGFwOi8vcm9vdGRpci5tYW5hZ2VkLmVudHJ1c3QuY29tL291PUVudHJ1c3QlMjBNYW5hZ2VkJTIwU2VydmljZXMlMjBSb290JTIwQ0Esb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89RW50cnVzdCxjPVVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5LGNyb3NzQ2VydGlmaWNhdGVQYWlyO2JpbmFyeTANBgNVHTYBAf8EAwIBADAPBgNVHSQBAf8EBTADgQEAMA4GA1UdDwEB/wQEAwIBBjAfBgNVHSMEGDAWgBStDHp1XOXzmMR5mA6sKP2X9OcC/DA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vaHR0cC5mcGtpLmdvdi9mY3BjYS9mY3BjYS5jcmwwHQYDVR0OBBYEFKlTvmSEg0tdJsYnPi7RhGhVPNB1MA0GCSqGSIb3DQEBCwUAA4IBAQA8VMdq1jzIj7WVFDBCb5wtPqnes4/Y+xB2mvx7ZdxJhkWxUIR8v0zmFaZOCxIzAk3q/Wl0cBUgBT0hALdxFrV6Fw3DTABqu9u9QdnB9k6IC9Wqesy5IIs6w75r16/v8traQBrgt6U75SidEeUPIRldqg6X8Pt0LiEt7mFxsZWlDXbRdo/YAADQSt426EWw6wEt+oG7Fo7bic0YrMfo9vNAep3BvztR9bCJXQTTeDSEPt3/RKOs6EcPjDuWXhRZoCQJ04RxIKPrTYy6Ycf/WvA7jWhSyZcWXLblFL7xKpECDyrt0EDNdb5wxsqWfb707CKN4hRTL4aPsfhBlQsMXfWa
-----END CERTIFICATE-----

Easily reproducible using even a more modern nss, nss-3.41.0-3.fc28.x86_64

I filed an upstream bug aginst nss, https://bugzilla.mozilla.org/show_bug.cgi?id=1525985

The only workaround would be to ignore the error in ipapython/certdb.py in verify_ca_cert_validity()

Initial feedback from NSS devel in the upstream BZ is not encouraging, but RFC 5280 does require support for inhibit anyPolicy and I have reflected this info into the upstream bug.

A less drastic workaround (compared to ignoring validation errors) could be to set NSS_ENABLE_PKIX_VERIFY=1 in the certutil process environment, to force it to use libpkix for validation. I would be hesitant to implement that as the fix though, because there is some stuff that works correctly in the "classic" validation routine that is not handled correctly by libpkix**.

** e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1523484

This is great support, thanks! Since the certutil command is being called through ipa-cacert-manage, what would be the best way to implement one of the workarounds? I'm guessing that the problem only exists during the initial installation of the CA cert (though I could be wrong); if so, then I just need to get it installed and then I can back out the workaround, assuming that I don't run into issues with the 3rd level CA, or client validation.

What I'm really trying to get done is authenticating users with federal PIV cards over SSH to systems joined to the IPA domain, which is mapping the user certs back to an AD account. I've got functional certificate mapping/matching rules, and can successfully match the cert to the intended user account. I guess I'm questioning whether the IPA domain really needs to trust the chain from which the user cert is issued (current functionality seems to require it) when the authentication is really happening back at Active Directory instead of within IPA.

@mpreissner let me respond point by point.

• How to implement the workaround? Running ipa-cacert-manage with NSS_ENABLE_PKIX_VERIFY=1 in process environment should work. If you do this (and if it works) then there is no workaround to "back out", it's just a transient environment variable.

• Problem only exists during initial installation of CA cert? That's my hunch too, but I haven't tested it and can't say for certain that there won't be other issues. In particular, with NSS default cert validation behaviour having this problem, it is likely that some clients (including Firefox) will experience problems. But note that Dogtag uses libpkix for validation, and the FreeIPA framework and CLI client use OpenSSL under the hood (via python-cryptography), so I think (but don't guarantee) that the FreeIPA infrastructure itself shouldn't experience issues.

• I believe trust of the user cert is necessary but am pinging @sbose for comment.

NSS closed the bug as wontfix so we won't be getting a change to certutil.

@rcritten therefore we too will have to close this wontfix. You'll have to use one of the workarounds (or get an externally-signed CA cert without the inhibit anyPolicy extension.

I'll close it now. If anyone disagrees feel free to continue the discussion, but without a fix in NSS there isn't much we can do...