[SERVER-45802] Limit frequency of X.509 client certificate expiry warnings Created: 27/Jan/20  Updated: 30/Jan/20  Resolved: 30/Jan/20

Status: Closed
Project: Core Server
Component/s: Security, Usability
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Spencer Jackson Assignee: Sara Golemon
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Security 2020-02-10
Participants:

 Description   

During connection establishment, if a client certificate is presented whose expiration is within tlsX509ExpirationWarningThresholdDays, a warning is emitted. This can result in many warnings.

To limit these warnings, we should record observed certificates along with a timestamp of when they were last warned about. This information should be stored in an LRU cache to bound it.

We should warn if the presented certificate is expiring soon, and is either not contained in the cache, or the time it was last warned about is sufficiently far in the past.



 Comments   
Comment by Sara Golemon [ 30/Jan/20 ]

I think this frequency counts as "working as designed" since we want system administrators to be able to act proactively to replace expiring client certificates before they become a problem.

Comment by Ravind Kumar (Inactive) [ 28/Jan/20 ]

Output from a mongod log where another replica set member presents a tlsClusterFile that is < tlsX509ExpirationWarningThresholdDays:

2020-01-24T14:27:22.382+0000 W  NETWORK  [conn6] Peer certificate 'CN=RKMongoServerBaker,OU=RKMongoTestServers,O=RKMongoTestOrg,L=NewYork,ST=NewYork,C=US' expires in 19d
2020-01-24T14:27:22.382+0000 I  NETWORK  [conn6] received client metadata from 127.0.0.1:52528 conn6: { driver: { name: "NetworkInterfaceTL", version: "4.3.2-18-gb336760" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "18.04" } }
2020-01-24T14:27:22.384+0000 I  NETWORK  [listener] connection accepted from 127.0.0.1:52530 #7 (4 connections now open)
2020-01-24T14:27:22.398+0000 W  NETWORK  [conn7] Peer certificate 'CN=RKMongoServerBaker,OU=RKMongoTestServers,O=RKMongoTestOrg,L=NewYork,ST=NewYork,C=US' expires in 19d
2020-01-24T14:27:22.398+0000 I  NETWORK  [conn7] received client metadata from 127.0.0.1:52530 conn7: { driver: { name: "MongoDB Internal Client", version: "4.3.2-18-gb336760" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "18.04" } }
2020-01-24T14:27:23.067+0000 I  NETWORK  [conn7] end connection 127.0.0.1:52530 (3 connections now open)
2020-01-24T14:27:23.067+0000 I  NETWORK  [listener] connection accepted from 127.0.0.1:52532 #8 (4 connections now open)
2020-01-24T14:27:23.080+0000 W  NETWORK  [conn8] Peer certificate 'CN=RKMongoServerBaker,OU=RKMongoTestServers,O=RKMongoTestOrg,L=NewYork,ST=NewYork,C=US' expires in 19d
2020-01-24T14:27:23.080+0000 I  NETWORK  [conn8] received client metadata from 127.0.0.1:52532 conn8: { driver: { name: "NetworkInterfaceTL", version: "4.3.2-18-gb336760" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "18.04" } }
2020-01-24T14:27:24.077+0000 I  REPL     [ReplCoord-1] Member 127.0.0.1:27200 is now in state SECONDARY

Note that we throw the Peer certificate warning per incoming from the member mongod, resulting in multiple warnings in the logs. I only tested this in a small replica set, but this might be more dramatic in a 3+ member replica set or sharded cluster where multiple members reach near-expiry at the same time.

Generated at Thu Feb 08 05:09:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.