Cryptography 35.0.0 fails to parse FreeIPA server CSR

[tiran]

Cryptograhy 35.0.0 fails to parse a CSR generated by FreIPA 4.9 / certmonger. The certificate contains three additional fields that are uncommon:

• SAN OtherName szOID_NT_PRINCIPAL_NAME (1.3.6.1.4.1.311.20.2.3)
• SAN OtherName Kerberos V5 pkinit (1.3.6.1.5.2.2)
• Microsoft szOID_ENROLL_CERTTYPE (1.3.6.1.4.1.311.20.2) extension

While writing the bug report, Alex pointed out that the issue is caused by the critical field. The critical field is encoded although the value is equal to the default value. In DER fields should not be encoded if the value matches the default value.

$ openssl asn1parse -inform PEM -in freeipa.csr
...
  421:d=7  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative Name
  426:d=7  hl=2 l=   1 prim: BOOLEAN           :0
  429:d=7  hl=3 l= 135 prim: OCTET STRING      [HEX DUMP]:...
...

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING
                    -- contains the DER encoding of an ASN.1 value
                    -- corresponding to the extension type identified
                    -- by extnID
        }

Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: O = IPA.TEST, CN = replica1.ipa.test
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:e5:3c:d0:66:92:a0:5a:ee:2f:e0:b9:97:e3:8c:
                    51:0a:00:36:0d:cb:d8:e0:3e:cb:c3:f6:72:af:7b:
                    9c:87:9e:20:bc:05:16:8b:6a:22:fc:f6:15:8b:12:
                    50:35:51:df:64:87:24:82:b3:d1:3b:e8:2d:31:a1:
                    6c:5e:e2:07:81:61:e3:cb:64:dd:14:d3:95:e5:46:
                    af:dd:6d:3b:7e:5d:bc:9e:78:26:01:67:7c:4a:ae:
                    16:fa:2e:ef:9c:13:29:eb:6b:33:b4:4d:27:a2:64:
                    d4:7b:fe:76:0f:e5:77:a6:08:02:ce:a5:65:bc:5b:
                    c0:83:c2:2a:c7:26:af:0d:0f:7b:e0:8d:77:57:64:
                    ae:bc:95:49:ec:49:e5:68:29:cd:64:f4:57:2f:52:
                    02:9e:cc:ca:7c:88:68:2d:61:fc:71:b0:5a:c4:70:
                    a3:66:41:c4:22:7b:bc:ee:a6:fd:38:73:69:7a:fa:
                    f3:e4:e2:4c:5f:61:c6:d7:82:1c:d7:92:39:da:5d:
                    18:55:30:50:42:bd:40:40:51:83:36:94:aa:b7:e3:
                    5e:a0:24:a2:63:d1:7b:9e:11:17:76:48:2f:86:4d:
                    eb:31:5d:a7:93:65:c9:ba:df:58:22:c1:09:62:8e:
                    12:2b:4a:41:4f:17:52:51:81:ec:c9:9a:ab:3f:f7:
                    1d:17
                Exponent: 65537 (0x10001)
        Attributes:
            friendlyName             :unable to print attribute
        Requested Extensions:
            X509v3 Subject Alternative Name: 
                DNS:replica1.ipa.test, othername:<unsupported>, othername:<unsupported>
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier: 
                FB:4B:BE:4D:91:72:02:B0:29:F2:28:D0:2A:7C:3E:FA:7B:5E:ED:F0
            1.3.6.1.4.1.311.20.2: 
                . .c.a.I.P.A.s.e.r.v.i.c.e.C.e.r.t
    Signature Algorithm: sha256WithRSAEncryption
         d6:31:17:f6:e5:d2:02:f0:e3:3f:a6:51:c5:3e:56:a3:60:d6:
         cb:8c:aa:27:1e:7e:b4:ed:b5:8e:ba:51:80:22:ae:a3:05:21:
         c3:2c:c4:16:20:3f:58:34:3f:bf:2f:57:1a:ab:dc:45:a4:69:
         91:d6:f0:ad:c9:9e:7e:f5:02:82:9a:ce:05:e3:63:47:51:76:
         68:a4:c7:9e:06:87:e1:66:d6:77:80:48:d2:54:74:67:55:99:
         ba:f2:f6:7d:11:83:bc:e0:90:00:63:55:c8:6b:ed:c5:5f:b5:
         e6:89:56:ab:bd:fc:e9:f1:1e:dc:f0:07:17:da:2c:5e:97:07:
         f7:b2:a2:7c:bd:7e:78:6d:95:91:aa:a8:e3:2c:a5:50:69:9e:
         fd:18:a7:e2:f1:b3:c6:48:c6:60:4f:8e:fe:e8:31:b6:08:a5:
         e5:53:ec:d2:7a:c9:c7:46:c5:59:a3:0b:2b:dc:84:ae:ff:4e:
         d5:5d:c9:48:aa:0b:9f:ec:80:2b:1a:d8:42:e3:01:97:59:ea:
         a4:08:fd:3f:83:56:74:5b:06:97:75:1b:a6:7e:2f:c2:2b:70:
         6a:af:69:90:4b:b4:2b:56:7e:08:fe:45:5c:ec:85:b2:01:06:
         2a:77:0b:e2:0b:9b:f0:84:02:ef:6d:01:db:90:3c:62:8c:06:
         4e:4d:c1:37
-----BEGIN CERTIFICATE REQUEST-----
MIIDqzCCApMCAQAwLzERMA8GA1UEChMISVBBLlRFU1QxGjAYBgNVBAMTEXJlcGxp
Y2ExLmlwYS50ZXN0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5TzQ
ZpKgWu4v4LmX44xRCgA2DcvY4D7Lw/Zyr3uch54gvAUWi2oi/PYVixJQNVHfZIck
grPRO+gtMaFsXuIHgWHjy2TdFNOV5Uav3W07fl28nngmAWd8Sq4W+i7vnBMp62sz
tE0nomTUe/52D+V3pggCzqVlvFvAg8IqxyavDQ974I13V2SuvJVJ7EnlaCnNZPRX
L1ICnszKfIhoLWH8cbBaxHCjZkHEInu87qb9OHNpevrz5OJMX2HG14Ic15I52l0Y
VTBQQr1AQFGDNpSqt+NeoCSiY9F7nhEXdkgvhk3rMV2nk2XJut9YIsEJYo4SK0pB
TxdSUYHsyZqrP/cdFwIDAQABoIIBNTAlBgkqhkiG9w0BCRQxGB4WAFMAZQByAHYA
ZQByAC0AQwBlAHIAdDCCAQoGCSqGSIb3DQEJDjGB/DCB+TCBkgYDVR0RAQEABIGH
MIGEghFyZXBsaWNhMS5pcGEudGVzdKAvBgorBgEEAYI3FAIDoCEMH2xkYXAvcmVw
bGljYTEuaXBhLnRlc3RASVBBLlRFU1SgPgYGKwYBBQICoDQwMqAKGwhJUEEuVEVT
VKEkMCKgAwIBAaEbMBkbBGxkYXAbEXJlcGxpY2ExLmlwYS50ZXN0MAwGA1UdEwEB
/wQCMAAwIAYDVR0OAQEABBYEFPtLvk2RcgKwKfIo0Cp8Pvp7Xu3wMDIGCSsGAQQB
gjcUAgEBAAQiHiAAYwBhAEkAUABBAHMAZQByAHYAaQBjAGUAQwBlAHIAdDANBgkq
hkiG9w0BAQsFAAOCAQEA1jEX9uXSAvDjP6ZRxT5Wo2DWy4yqJx5+tO21jrpRgCKu
owUhwyzEFiA/WDQ/vy9XGqvcRaRpkdbwrcmefvUCgprOBeNjR1F2aKTHngaH4WbW
d4BI0lR0Z1WZuvL2fRGDvOCQAGNVyGvtxV+15olWq7386fEe3PAHF9osXpcH97Ki
fL1+eG2Vkaqo4yylUGme/Rin4vGzxkjGYE+O/ugxtgil5VPs0nrJx0bFWaMLK9yE
rv9O1V3JSKoLn+yAKxrYQuMBl1nqpAj9P4NWdFsGl3Ubpn4vwitwaq9pkEu0K1Z+
CP5FXOyFsgEGKncL4gub8IQC720B25A8YowGTk3BNw==
-----END CERTIFICATE REQUEST-----

[alex]

As discussed on IRC, I think it's correct that this is rejected, based on the rules of DER. It's unfortunate that OpenSSL ever allowed it.

It'd be good to figure out what's generating these non-conforming values. And we should probably document this in the changelog.

[tiran]

The problem is caused by an invalid template in certmonger. Certmonger uses NSS routines to generate a X509v3 extension blob, then pushes the blob into OpenSSL using X509_REQ_add1_attr_by_NID(). Certmonger's cm_certext_cert_extension_template defines the critical extension as .kind = SEC_ASN1_BOOLEAN. The correct definition from NSS' certdb is SEC_ASN1_OPTIONAL | SEC_ASN1_BOOLEAN.

OpenSSL happily accepts the DER.

[tiran]

Certmonger issue: https://pagure.io/certmonger/issue/223

FreeIPA issue: https://pagure.io/freeipa/issue/9005

[tiran]

According to ITU X.690 standard 202102:

11 Restrictions on BER employed by both CER and DER

11.5 Set and sequence components with default value

The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value.

[tiran]

Alex found https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der/#sequence-encoding

DEFAULT fields are similar to OPTIONAL ones. If a field’s value is the default, it may be omitted from the BER encoding. In the DER encoding, it MUST be omitted.

[tiran]

I did some testing with crypto libraries. asn1crypto refuses to load the broken CSR, too. pyasn1, https://lapo.it/asn1js/, NSS certutil -C, and OpenSSL openssl req don't complain.

[jschanck]

I've encountered this issue with several certificates as well. Here's an intermediate CA certificate where the X509v3 Extended Key Usage extension has an explicitly encoded critical=False.

-----BEGIN CERTIFICATE-----
MIIFoDCCA4igAwIBAgIQUuhDsZZ+VM6gWSw3oW+alDANBgkqhkiG9w0BAQsFADBH
MQswCQYDVQQGEwJDTjERMA8GA1UECgwIVW5pVHJ1c3QxJTAjBgNVBAMMHFVDQSBF
eHRlbmRlZCBWYWxpZGF0aW9uIFJvb3QwHhcNMTgwNDI3MTYwMDAwWhcNMzMwNDI3
MTU1OTU5WjBSMQswCQYDVQQGEwJDTjERMA8GA1UECgwIVW5pVHJ1c3QxMDAuBgNV
BAMMJ1NIRUNBIFJTQSBFeHRlbmRlZCBWYWxpZGF0aW9uIFNlcnZlciBDQTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALrO2TwT/q2v7fcZfa0lkJ9pE8IH
qVZXzLayN6CMEucJ0pJUjsnpt8SOMYhefJ/gpwtZOKasfY7vc0EOwd7IZEPco5yn
0ERh9y/o53G2RICEopGpWoOMKYtfw+YCkes5P4ucMCJfwlH3YRUb8bko5QCO84Y3
kI6oIaHp7+gY9vwmwKXp2FH4bG/V2SxHhSCW9tUSoTzd0rxGAlq2Sd2GyzJnmWnh
G4fWvgC+NZfwxc+REMy5OCJ3PxT+F98FlG2t9bpw00RVi8g7O03RYOqT0nzbSUvX
tuKaQTiXYtfqayJuVa7MpOy0w2P1NP/aslHxdvsjiUEeOhhHLJplavB/+s0CAwEA
AaOCAXswggF3MA4GA1UdDwEB/wQEAwIBBjBBBgNVHSAEOjA4MDYGBFUdIAAwLjAs
BggrBgEFBQcCARYgaHR0cHM6Ly93d3cuc2hlY2EuY29tL3JlcG9zaXRvcnkwEgYD
VR0TAQH/BAgwBgEB/wIBADB1BggrBgEFBQcBAQRpMGcwNgYIKwYBBQUHMAGGKmh0
dHA6Ly9vY3NwMy5zaGVjYS5jb20vb2NzcC9yb290L3Jvb3Qub2NzcDAtBggrBgEF
BQcwAoYhaHR0cDovL2NlcnRzLnNoZWNhLmNvbS9yL2V2ZzEuY2VyMB0GA1UdDgQW
BBQ7SyUqdzcq/Ll/7ai9ryKZ/F3F9DAfBgNVHSMEGDAWgBTZdDrkMD0N9xLcfloF
nx40mvfhFDAgBgNVHSUBAQAEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwNQYDVR0f
BC4wLDAqoCigJoYkaHR0cDovL2xkYXAyLnNoZWNhLmNvbS9yb290L2V2ZzEuY3Js
MA0GCSqGSIb3DQEBCwUAA4ICAQAceBs7lYtmgYahhFm+pZPEo3k2khX5NsQtA8rW
vtkyQ54YNJaMCy72lW/FAwC4NnTxPiwOeVSH10kPyRVYBelHs7D6MR19ZV98i+Lz
TgSYxyFh9wvGl4pML+anNZk0yjLlkYRcCiWAql9Q205FmUcgZ8KnzFN+J8li8Ia0
C1jYKjMGVcGHD+/RoV9eLLpdeqj4Ez8XLzth09m7DFEe+F17yeXTZRmn3yO4ErKm
cVApwQOpibIeqW/eht8bpesvfL4WbnJPchw5w7/ed4mQ498SYxtHvD4b+7U4WyVp
Bev+RylreBxxxtThD/++PTGNb3pxzPM56Ff6uHHrTTzWdSt0u5tSdESkUfbJt0fR
ggSD32YA8Oo3C179cYbYEgskYfXXyePe00Yr5drfKfujAlvrO7fD7Zf/U6xFFwWB
sw7PRYd9HSlttOc1MdWzcn1BvB9+8lQ1Q1mUBxryROd5DgbJoAKa7e7dF4ONCVt4
zvzIOpYMrflIoeoFM8YWC7xP9Bj/YyRbqm8WLJ8rQSavrORLqpBKp/FKmyQ9LzoS
W9e3c57wydKsUKN+9ckPVMHA0lHg4E1Afm+AXKqcbtnFe8TVvT1hEm2Ht1QAFQBt
GCfhREAyjEQwz04LLjzOsIKtqT/dp4PoKPVki71V2E1AgyrxhJi2DI2x6v2kl89z
XbDMqg==
-----END CERTIFICATE-----

[alex]

As discussed above, this cert is not actually valid within the definitions of the relevant standards. For us to fully understand the impact here, can you tell us what software was used to issue that cert? Is it still issuing invalid certs?