Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

prober/tls: fix probe_ssl_last_chain_expiry_timestamp_seconds #681

Merged
merged 2 commits into from
Aug 20, 2020

Conversation

ribbybibby
Copy link
Contributor

Apologies if I've misunderstood the purpose of this metric but I believe that it should be reporting the earliest expiry date of the chain that expires last out of all the verified chains. Presently it's reporting the earliest expiry of the chain that expires first.

This wasn't identified by the test for this metric because the test is using an expired root certificate which is not included in the VerifiedChains, so there was only one chain for the method to iterate over and therefore getLastChainExpiry returned the same regardless of the logic.

This metric should report the earliest expiry of the chain that expires
the latest out of all the verified chains. Presently, it reports the
earliest expiry of the chain that expires first.

The current test for this metric was using an expired root certificate which
is omitted from the verified chain, so the test was passing despite this
bug. I've changed it to use a root that is still valid but expires before a
root held by the client.

Signed-off-by: Rob Best <[email protected]>
@ribbybibby ribbybibby force-pushed the last-chain-expiry-fix branch from e4fcf2d to 9b3d63f Compare August 19, 2020 19:59
@brian-brazil
Copy link
Contributor

Your change seems correct, @itkq did you miss this in your testing?

The unittest still doesn't seem right, we should have a test with different values for the two metrics.

Include the older root certificate in the chain presented by the server
as well as in the client root CAs. This ensures that the peer
certificate metric identifies the older root CA as the earliest expiry
while it is ignored by the verified metric in favour of the longer-lived
chain.

Signed-off-by: Rob Best <[email protected]>
@ribbybibby
Copy link
Contributor Author

@brian-brazil I've tweaked the test. I think this captures the situation this metric was put in place to address now: the server presents a root cert that expires before the server cert, despite the client holding another, valid, longer-lived root.

@itkq
Copy link
Contributor

itkq commented Aug 20, 2020

This change seems right for me. I'm sorry, I should have noticed that VerifiedChains didn't have multiple chains in testing.

@brian-brazil brian-brazil merged commit 7913a15 into prometheus:master Aug 20, 2020
@brian-brazil
Copy link
Contributor

Thanks!

@ribbybibby ribbybibby deleted the last-chain-expiry-fix branch August 20, 2020 12:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants