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

Check if TLS certificate and key file have been modified #345

Merged

Conversation

LeviHarrison
Copy link
Member

This PR adds the capability to check the hashes of the client certificate and key files to see if they've been modified, as is already done with the CA file.

Fixes prometheus/prometheus#9512

@roidelapluie
Copy link
Member

I think we should only store the cert, you can not change the key without changing the cert.

@LeviHarrison
Copy link
Member Author

LeviHarrison commented Nov 26, 2021

The issue with that would be if someone were to change only the key, yes, the TLS configuration would be invalid, but instead of getting (what I think would be) a private key does not match public key error, they would continue to get whatever error they had before or nothing, because the configuration wouldn't be updated.

config/http_config.go Outdated Show resolved Hide resolved
}
h1 := sha256.Sum256(b1)

b2, b3, err := readCertAndKey(t.certFile, t.keyFile)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where do we deal with unset certFile and t.keyFile?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please elaborate on what you mean by unset?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean empty strings

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. A round tripper just isn't created if the CAFile is unset, but we can't do the same with the certFile and keyFile.

if len(cfg.TLSConfig.CAFile) == 0 {
// No need for a RoundTripper that reloads the CA file automatically.
return newRT(tlsConfig)
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be fixed.

@fpetkovski
Copy link

fpetkovski commented Mar 1, 2022

We are also hitting this problem, anything we can help with to move the PR forward?

@LeviHarrison
Copy link
Member Author

Apologies, I just need to find time to work on this.

@simonpasquier
Copy link
Member

@LeviHarrison do you want me to pick up the work? This bug is becoming a significant issue for us right now.

@roidelapluie
Copy link
Member

@LeviHarrison do you want me to pick up the work? This bug is becoming a significant issue for us right now.

Yes, I think you can review&rebase

@simonpasquier simonpasquier force-pushed the tls-roundtripper-check-cert-key branch from e06f022 to 9294f56 Compare July 8, 2022 12:39
@simonpasquier
Copy link
Member

Rebased on top of main, I didn't change anything to the PR except for resolving the conflicts. Thanks a lot @LeviHarrison!

LeviHarrison and others added 8 commits July 13, 2022 18:01
Signed-off-by: Levi Harrison <git@leviharrison.dev>

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
Signed-off-by: Levi Harrison <git@leviharrison.dev>

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
Signed-off-by: Levi Harrison <git@leviharrison.dev>

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
Signed-off-by: Levi Harrison <git@leviharrison.dev>

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
Signed-off-by: Levi Harrison <git@leviharrison.dev>

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
This reverts commit c63387b.

Signed-off-by: Levi Harrison <git@leviharrison.dev>

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
Signed-off-by: Levi Harrison <git@leviharrison.dev>

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
@simonpasquier simonpasquier force-pushed the tls-roundtripper-check-cert-key branch from 9294f56 to d3fa312 Compare July 13, 2022 16:02
@simonpasquier
Copy link
Member

@roidelapluie PTAL

@simonpasquier
Copy link
Member

@roidelapluie friendly ping :)

simonpasquier added a commit to simonpasquier/prometheus that referenced this pull request Oct 26, 2022
When the TLS certificate (used by Prometheus to authenticate to the
scraped targets) gets rotated, Prometheus doesn't pick up the new
certificate until the connection to the target is re-established.
Because Prometheus uses keep-alive HTTP connections, the consequence is
that the scrapes start failing after about 1 day and the TargetDown
alert fires.

There's an upstream pull request [1] to address the issue but it isn't
merged yet. This commit pulls the changes from [1] into our downstream
fork by adding a replace directive to go.mod for the
github.com/prometheus/common. The replacement code is under
patches/github.com/prometheus/common which is the same version as
upstream (v0.37.0) + the upstream PR applied on top of it.

As soon as upstream Prometheus depends on a version of
github.com/prometheus/common that fixes the issue, the replace directive
in go.mod and the code under the patches/ directory can be removed.

[1] prometheus/common#345

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
simonpasquier added a commit to simonpasquier/prometheus that referenced this pull request Oct 26, 2022
When the TLS certificate (used by Prometheus to authenticate to the
scraped targets) gets rotated, Prometheus doesn't pick up the new
certificate until the connection to the target is re-established.
Because Prometheus uses keep-alive HTTP connections, the consequence is
that the scrapes start failing after about 1 day and the TargetDown
alert fires.

There's an upstream pull request [1] to address the issue but it isn't
merged yet. This commit pulls the changes from [1] into our downstream
fork by adding a replace directive to go.mod for the
github.com/prometheus/common. The replacement code is under
patches/github.com/prometheus/common which is the same version as
upstream (v0.37.0) + the upstream PR applied on top of it.

As soon as upstream Prometheus depends on a version of
github.com/prometheus/common that fixes the issue, the replace directive
in go.mod and the code under the patches/ directory can be removed.

[1] prometheus/common#345

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
simonpasquier added a commit to simonpasquier/prometheus that referenced this pull request Oct 26, 2022
When the TLS certificate (used by Prometheus to authenticate to the
scraped targets) gets rotated, Prometheus doesn't pick up the new
certificate until the connection to the target is re-established.
Because Prometheus uses keep-alive HTTP connections, the consequence is
that the scrapes start failing after about 1 day and the TargetDown
alert fires.

There's an upstream pull request [1] to address the issue but it isn't
merged yet. This commit pulls the changes from [1] into our downstream
fork by adding a replace directive to go.mod for the
github.com/prometheus/common. The replacement code is under
patches/github.com/prometheus/common which is the same version as
upstream (v0.37.0) + the upstream PR applied on top of it.

As soon as upstream Prometheus depends on a version of
github.com/prometheus/common that fixes the issue, the replace directive
in go.mod and the code under the patches/ directory can be removed.

[1] prometheus/common#345

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
simonpasquier added a commit to simonpasquier/prometheus that referenced this pull request Oct 26, 2022
When the TLS certificate (used by Prometheus to authenticate to the
scraped targets) gets rotated, Prometheus doesn't pick up the new
certificate until the connection to the target is re-established.
Because Prometheus uses keep-alive HTTP connections, the consequence is
that the scrapes start failing after about 1 day and the TargetDown
alert fires.

There's an upstream pull request [1] to address the issue but it isn't
merged yet. This commit pulls the changes from [1] into our downstream
fork by adding a replace directive to go.mod for the
github.com/prometheus/common. The replacement code is under
patches/github.com/prometheus/common which is the same version as
upstream (v0.37.0) + the upstream PR applied on top of it.

As soon as upstream Prometheus depends on a version of
github.com/prometheus/common that fixes the issue, the replace directive
in go.mod and the code under the patches/ directory can be removed.

[1] prometheus/common#345

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
@roidelapluie
Copy link
Member

Thanks!

openshift-cherrypick-robot pushed a commit to openshift-cherrypick-robot/prometheus that referenced this pull request Nov 23, 2022
When the TLS certificate (used by Prometheus to authenticate to the
scraped targets) gets rotated, Prometheus doesn't pick up the new
certificate until the connection to the target is re-established.
Because Prometheus uses keep-alive HTTP connections, the consequence is
that the scrapes start failing after about 1 day and the TargetDown
alert fires.

There's an upstream pull request [1] to address the issue but it isn't
merged yet. This commit pulls the changes from [1] into our downstream
fork by adding a replace directive to go.mod for the
github.com/prometheus/common. The replacement code is under
patches/github.com/prometheus/common which is the same version as
upstream (v0.37.0) + the upstream PR applied on top of it.

As soon as upstream Prometheus depends on a version of
github.com/prometheus/common that fixes the issue, the replace directive
in go.mod and the code under the patches/ directory can be removed.

[1] prometheus/common#345

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
roidelapluie added a commit to roidelapluie/prometheus that referenced this pull request Dec 8, 2022
- Check if TLS certificate and key file have been modified
  prometheus/common#345
- Add the ability to specify the maximum acceptable TLS version
  prometheus/common#414

Signed-off-by: Julien Pivotto <roidelapluie@o11y.eu>
radek-ryckowski pushed a commit to goldmansachs/common that referenced this pull request May 18, 2023
)

* Check hash of cert and key file

Signed-off-by: Levi Harrison <git@leviharrison.dev>

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
radek-ryckowski pushed a commit to goldmansachs/common that referenced this pull request May 22, 2023
)

* Check hash of cert and key file

Signed-off-by: Levi Harrison <git@leviharrison.dev>

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants