Skip to content

x509 signed commits feature enforces a 40 character (hex) Subject Key Identifier but some are only 16 long

Summary

A customer raised a ticket to report that a git repository was malfunctioning after a developer signed a commit with their x509 smart card. (GitLab team members can read more in the ticket)

This was caused by two issues. The malfunctioning is addressed by #332464 (closed).

The error that wasn't being trapped related to X509v3 Subject Key Identifier validation which the GitLab code enforces as 40 characters, eg:

            X509v3 Subject Key Identifier:
                A0:73:49:99:68:DC:85:5B:65:E3:9B:28:2F:57:9F:BD:33:BC:07:48

However, the customer's root, intermediates, and client certs (on smart cards) are all shorter:

            X509v3 Subject Key Identifier:
                4A:A0:AA:58:84:D3:5E:3C

They're not alone. Public root Sonera_Class_2_Root_CA.pem "Sonera Class2 CA" issued in 2003 has the short SKI, though of all public roots on Ubuntu 18.04, that's the only one.

The customer's root was issued in 2013, and is valid to 2029.

Steps to reproduce

Sign a commit with a valid certificate that has a short Subject Key Identifier.

(Or possibly run a short SKI through via the test code, eg spec/factories/x509_issuer.rb etc ?)

Example Project

What is the current bug behavior?

Signed commits do not validate when the signer and issuer use a short SKI.

What is the expected correct behavior?

Signed commits validate, if all other checks pass.

Relevant logs and/or screenshots

Output of checks

13.11.4

Possible fixes

As the customer's client certs AND CA certs have short SKIs, the two places with the following code cause problems. The customer tested by remarking both out.

validates :subject_key_identifier, presence: true, format: { with: /\A(\h{2}:){19}\h{2}\z/ }

Am I reading that regex right? Two hex characters plus a colon ((\h{2}:)), 19 off ({19}) plus another (h{2})?

Do we need to validate the length of the SKI?

The standards have clearly changed over time, and TLS being TLS, they'll change again in the future.

I've looked in the RFC, and can't see where this specific length is identified.

app/models/x509_certificate.rb

app/models/x509_issuer.rb

RFC5280 is dated May 2008. I can't see where it strictly specifies how long these numbers should be, but even if it does, root certificates typically last 20 or more years. A 2007/8 root certificate still has at least another 6 years to run. This customer's was issued in 2013 for just 16 years, but still has has another eight years to run. They'll probably need to start working on replacing it in a couple of years, but deploying new root(s) across an enterprise is a huge undertaking.

Edited by Ben Prescott_