Many SSL servers implement (Mutual Transport Layer Security (mTLS) -- a security protocol where both the client and the server authenticate each other's identities using digital certificates. But SSL certificate lifespans are shrinking -- down to 47 days by 2029. Simultaneously, browser makers are forcing CAs to stop issuing SSL certificates that allow both server and client authentication (mTLS) on the same certificate. This is a lethal one-two punch. It effectively ends the use of public certificates in system-to-system client certificate authentication.
IBM webMethods has released an Extended Key Usage (EKU) Bypass feature in My webMethods Server for mTLS (mutual TLS) client authentication. This feature allows MWS to accept client certificates that lack the 'clientAuth' EKU value, while maintaining all other security validations. However, this is a stopgap measure. By 2029, SSL certificate lifespans will have shrunk to 47 days. Most organisations cannot manually obtain and reconfigure dozens of client certificates every 47 days. Without any means to automate distribution and reconfiguration of client authentication certificates, the certificates will expire and authentication will fail.
A Way Forward - Distribute Client Certificate Updates via DNS Records
This idea proposes to automatically distribute client certificate information via DNS. A server would publish information about its updated client certificate in DNS. It would also use DNS to update its installed base of client authentication certificates.
It is based on the concept of DNS-based Authentication of Named Entities (DANE). DANE basically automates distribution of an entity's SSL certificate using a side-channel -- DNS -- that is available to any authenticating entity.
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities
This is a powerful concept that can be applied to client certificate authentication. An Internet Draft extends DANE to cover the authentication of clients publishing their certificate credentials in DNS via TLSA records:
TLS Client Authentication via DANE TLSA records
For it to work,
- The client must have previously put their certificate (or its hash) in their DNS 'TLSA' record and given it enough time to propagate. Ideally, the client uses DNSSEC to secure their DNS records, but this isn't strictly necessary.
- During SSL/TLS client authentication, the client presents its X.509 certificate to the server as part of the handshake process.
- The server first checks that a trusted Certificate Authority (CA) has vouched for the client certificate. This is the 'first witness'.
- Next, the server matches a certificate property (say, 'Common Name' or CN), with a user account preconfigured on the server. If not matched, the certificate does not authenticate a specific user.
- Finally, the server cross-checks the certificate with the client's DNS TLSA record. To do this, it obtains a domain name (say, from the CN), looks-up the DNS TLSA record, and matches the presented certificate with either the hash (or the full certificate) stored in the DNS TLSA record.
These modifications are proposed to the above standards:
PKIX-EE Focus.
The SSL client sets up DNS TLSA records that indicate for PKIX-EE (Service Certificate Constraint) certificate usage mode. At runtime, the client present a certificate that does both -- chain to a CA the server trusts (traditional PKI), and match the certificate (or hash) in the DNS record. So the server must trust the certificate's issuing CA.
No DNSSEC Requirement (For PKIX-EE Clients).
DNSSEC is a doozy for most organisations to implement - a single digit percentage of domains have DNSSEC. So why not skip it for PKIX-EE clients? Yes, without DNSSEC, an attacker can spoof DNS records and trick the server entity into accepting a fake certificate. But this is mitigated by the PKIX-EE focus above. The original Internet Draft treats DNS as the primary trust anchor. For example, DANE-EE and DANE-TA usage modes bypass traditional PKI entirely. So, without DNSSEC, an attacker could forge TLSA records and the server would have no fallback if a hacked DNS records pointed to a self-signed certificate. But a client declaring PKIX-EE (usage 1) means the client certificate must chain to a CA the server already trusts. This CA would presumably would have confirmed ownership of the server specified in the CN, before issuing the certificate. This means we’re using DNS as a pinning layer on top of PKI, not its replacement. This changes the threat model considerably.
Offline Credential Store.
This is really an implementation detail to speedup authentication. Instead of validating DNS TLSA records on each TLS handshake, implement an offline certificate credential store on the server and update it on a regular basis. The credential store would store client certificate (or hashes) and map them to local accounts. A scheduled job would go over the store, pull in updated TLSA records from DNS and save changes to certificates or hashes locally if necessary (i.e., it'd create or delete the local copies of certificate or hashes that are mapped to local accounts)
The purpose of these suggested modifications to the Internet Draft is to efficiently distribute client certificate information via a side-channel (DNS), similar to how emails and phone calls were used in the old days to distribute certificates or verify hashes.
Reference: The concept arose from discussion here:
https://security.stackexchange.com/questions/281360/long-validity-ssl-certificates-are-needed-for-system-system-x-509-client-certifi
