kroeckx / x509lint Goto Github PK

In regards to
ERROR: Subject with organizationName but without stateOrProvince or localityName

It was not clear to me where this requirement comes from in https://tools.ietf.org/html/rfc5280
Would you please point me to that?

Also, does this apply to root certificates?

I get this error when running x509lint on the following root cert via crt.sh.
organizationalUnitName = AC RAIZ FNMT-RCM
organizationName = FNMT-RCM
countryName = ES
SHA-256(Certificate) EBC5570C29018C4D67B1AA127BAF12F703B4611EBC17B7DAB5573894179B93FA
SHA-1(Certificate) EC503507B215C4956219E2A89A5B42992C4C2C20

I asked about this in the mozilla.dev.security.policy:
https://groups.google.com/d/msg/mozilla.dev.security.policy/yV84X0xkkEo/cPyt4G7YCQAJ

There is agreement that section 7.1.4.2 of the BRs only applies to end-entity certificates.

Example: https://crt.sh/?id=946000423&opt=x509lint

I believe the "Invalid Type in SAN entry" error is triggered by the presence of a dNSName SAN entry in a cert with only a clientAuth EKU.

I don't think this violates RFC 5280 or X.509 rules.

Currently when comparing the commonName with the SAN field and it's using an international domain name in commonName, we're giving an error.

ASN1_STRING_cmpcase() should probably be replaced with something that uses ToASCII()

Certs with serial numbers that begin with 0x00 (to make the integer positive) followed by 0xFF are being incorrectly flagged with the "ASN1 integer not minimally encoded" error.

Example: https://crt.sh/?id=17295920&opt=x509lint

Certificates that only contain a clientAuth key purpose ID are allowed for subscriber certificates according to the BRs.

extKeyUsage (required)
Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or
both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present.
Other values SHOULD NOT be present. The value anyExtendedKeyUsage MUST NOT be
present.

7.1.2.3 Subscriber Certificates - Page 70.
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf

However, certificates that only contain a clientAuth EKU with a BR OID return a
"ERROR: Baseline Requirements policy present for non server authentication certificate" message.

It appears that the logic within checks.c : CheckPolicy is not precise.

if (GetBit(cert_info, CERT_INFO_SERV_AUTH) || GetBit(cert_info, CERT_INFO_ANY_EKU) || GetBit(cert_info, CERT_INFO_NO_EKU))
	{
		if ((IsNameObjPresent(subject, obj_givenName) || IsNameObjPresent(subject, obj_surname))
			&& !CabIVPresent)
		{
			/* Required by CAB 7.1.4.2.2c */
			SetError(ERR_NAME_NO_IV_POLICY);
		}
	}
	else
	{
		if (DomainValidated || IndividualValidated || CabIVPresent)
		{
			SetError(ERR_POLICY_BR);
		}
	}

Original commit: 4b596b1

It's currently limiting street addresses to 30 characters. But I was never sure if that's a correct limit or not. RFC5280 has:
StreetAddress ::= PDSParameter

and:
PDSParameter ::= SET {
printable-string PrintableString
(SIZE(1..ub-pds-parameter-length)) OPTIONAL,
teletex-string TeletexString
(SIZE(1..ub-pds-parameter-length)) OPTIONAL }

and:
ub-pds-parameter-length INTEGER ::= 30

But I think this only applies to the ORAddress of a GeneralName, while it's now checked as part of the Name / RDNSequence / RelativeDistinguishedName.

So I'm not sure it has a specific limit, and we should probably use ub_name instead of the current value of 30.

x509lint detects zero RSA modulus correctly but it does not seem to detect negative RSA modulus.
As RSA modulus is a product of two prime numbers which are positive, and therefore it must be positive.

Your lint program doesn't have any complaints about the first certificate in this PEM file, it doesn't have anything set for the subject.

This doesn't seem right, but I can't see anything in the standard that actually prohibits it for DV certificates. Is that right?

subject=
issuer=dnQualifier = 39e8cb96c6f29b1a, C = XX, O = Private CA, CN = CA
SHA1 Fingerprint=09:23:31:D5:51:C3:7B:4A:92:BF:95:86:32:71:60:62:FB:AA:47:A6
serial=39E8CB96C6F29B1A
notBefore=Jun 30 19:52:55 2017 GMT
notAfter=Sep 29 19:52:55 2020 GMT
-----BEGIN CERTIFICATE-----
MIICPDCCAeKgAwIBAgIIOejLlsbymxowCgYIKoZIzj0EAwIwSjEZMBcGA1UELhMQ
MzllOGNiOTZjNmYyOWIxYTELMAkGA1UEBhMCWFgxEzARBgNVBAoMClByaXZhdGUg
Q0ExCzAJBgNVBAMMAkNBMB4XDTE3MDYzMDE5NTI1NVoXDTIwMDkyOTE5NTI1NVow
ADBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABD+xQ17WvFr5KiId+SA9S70p+LNC
cCCYH6XvjWkn3p4AV7oDdh8N4T/R6oRiPtRztWJ1/lIbTXAJot9nRDLJB1ejgfsw
gfgwFgYDVR0RBA8wDYILdGVzdGhvc3QueHkwCQYDVR0TBAIwADAdBgNVHSUEFjAU
BggrBgEFBQcDAQYIKwYBBQUHAwIwCwYDVR0PBAQDAgOoMBMGA1UdIAQMMAowCAYG
Z4EMAQIBMB0GA1UdDgQWBBQCnfRVo9MHEV38C0I+d4pquBJcwjAfBgNVHSMEGDAW
gBSgnougoA7S3IsM3krmZU7RbQWUjjBSBggrBgEFBQcBAQRGMEQwIAYIKwYBBQUH
MAGGFGh0dHA6Ly9vY3NwLm15Lmhvc3QvMCAGCCsGAQUFBzAChhRodHRwOi8vbXku
Y2EvY2EuaHRtbDAKBggqhkjOPQQDAgNIADBFAiEA8xBJsQ4+u7AsJUGElWCWW9Mv
E4Azl+yavNUPUw7fS+0CICbjp5Li2qhQmbNvLsxDD+DstLfayY3rPPLNyKGaIBEL
-----END CERTIFICATE-----
subject=dnQualifier = 39e8cb96c6f29b1a, C = XX, O = Private CA, CN = CA
serial=C1BB5DAE5DC68CDC
notBefore=Jun 30 19:52:55 2017 GMT
notAfter=Sep 29 19:52:55 2020 GMT
-----BEGIN CERTIFICATE-----
MIIB3zCCAYSgAwIBAgIJAMG7Xa5dxozcMAoGCCqGSM49BAMCMEoxGTAXBgNVBC4T
EDM5ZThjYjk2YzZmMjliMWExCzAJBgNVBAYTAlhYMRMwEQYDVQQKDApQcml2YXRl
IENBMQswCQYDVQQDDAJDQTAeFw0xNzA2MzAxOTUyNTVaFw0yMDA5MjkxOTUyNTVa
MEoxGTAXBgNVBC4TEDM5ZThjYjk2YzZmMjliMWExCzAJBgNVBAYTAlhYMRMwEQYD
VQQKDApQcml2YXRlIENBMQswCQYDVQQDDAJDQTBZMBMGByqGSM49AgEGCCqGSM49
AwEHA0IABKMo3c/Q/sZbBykOgN48lAA9LQEqGK4KyLQKNq8ZuZZCoZMyi+dixESX
LS305aGW9vqygZ8iYDH9Y+lN6c4DA0KjUzBRMA8GA1UdEwQIMAYBAf8CAQAwHQYD
VR0OBBYEFKCei6CgDtLciwzeSuZlTtFtBZSOMB8GA1UdIwQYMBaAFKCei6CgDtLc
iwzeSuZlTtFtBZSOMAoGCCqGSM49BAMCA0kAMEYCIQCyuc8K3B/cqXtr+zUMWW1U
bagABTyXdOE6+4zmX6jBmAIhAMx0ree0ctXxF4FCNdi89qsGygpJotw+dxu/Oa4h
xfz0
-----END CERTIFICATE-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEINPphmXgcYEJNlTvH/TST32X1//zgvEFUT9EwQoq2O8YoAoGCCqGSM49
AwEHoUQDQgAEP7FDXta8WvkqIh35ID1LvSn4s0JwIJgfpe+NaSfengBXugN2Hw3h
P9HqhGI+1HO1YnX+UhtNcAmi32dEMskHVw==
-----END EC PRIVATE KEY-----

https://crt.sh/?id=32206470&opt=x509lint
"ERROR: Invalid type in SAN entry"

IINM, it's showing that error because x509lint treats certs that omit the EKU extension as invalid for each of the purposes (and the corresponding SubjectAltName fields) that can be enumerated by EKU OIDs.

But isn't no EKU extension essentially equivalent to EKU with the anyExtendedKeyUsage OID?

It appears that this is not currently in the BRs, but it should be...

Please show an error (or warning) when basicConstraints:cA is true and subject commonName is empty.

Reference:
https://groups.google.com/d/msg/mozilla.dev.security.policy/yV84X0xkkEo/hDkR1eUOCgAJ

I think the behavior of CAB LINT regarding non-TLS certificates is more appropriate: https://crt.sh/?id=1138256051&opt=cablint,x509lint . Maybe you could also disable linting for non-SSL/TLS certificates.