When creating custom TLS certs, add IPs to SANs as IPs and not DNS names#2457
Merged
Merged
Conversation
Some tests use IP addresses from http test servers for various Pelican server configs (e.g. 'Server.ExternalWebUrl'). When we do this, the certificates Pelican generates for itself are invalid because they contain a SAN that says the IP is a DNS entry. This was exposed in tests for PelicanPlatform#2035 after it picked up the new verification code that checks the cert against configured hostnames.
jhiemstrawisc
added
bug
Member
Author
|
@matyasselmeci I'm adding you as a co-reviewer because I'd like someone with a bit more TLS cert knowledge than I have to double check that what I'm saying is correct. |
Merged
h2zh
approved these changes
Jul 2, 2025
Collaborator
|
@jhiemstrawisc - did you catch which tests are using IP addresses? That seems to be the underlying problem here -- we should always use names. |
Member
Author
|
Indeed -- the offending test comes from using an Line 942 in c2068a1 |
Member
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The issue being fixed here is that some of our internal tests were producing bad certificates by adding IP addresses as DNS names, which was exposed recently when we started checking the configured certs against the configured server hostnames
This diff does two things -- it only toggles the cert<-->hostname validation when TLS is enabled in Pelican, and it adds the IP addresses to the cert correctly regardless.