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

x509.certificate_managed creates new certificate every run #52167

Closed
OrangeDog opened this issue Mar 13, 2019 · 31 comments · Fixed by #63099
Closed

x509.certificate_managed creates new certificate every run #52167

OrangeDog opened this issue Mar 13, 2019 · 31 comments · Fixed by #63099
Assignees
Labels
Bug broken, incorrect, or confusing behavior severity-high 2nd top severity, seen by most users, causes major problems

Comments

@OrangeDog
Copy link
Contributor

The state always creates a new certificate before it's confirmed whether one is needed.
If using a signing_policy with copypath, this can quickly fill the directory with thousands of certificates that were never used.

https://github.com/saltstack/salt/blob/v2018.3.4/salt/states/x509.py#L502
https://github.com/saltstack/salt/blob/v2018.2/salt/states/x509.py#L493

I notice on the develop branch, it's now creating two certificates every time.
https://github.com/saltstack/salt/blob/develop/salt/states/x509.py#L533

@Ch3LL
Copy link
Contributor

Ch3LL commented Mar 14, 2019

can you share your state where you are seeing this issue? thanks

@Ch3LL Ch3LL added the info-needed waiting for more info label Mar 14, 2019
@Ch3LL Ch3LL added this to the Blocked milestone Mar 14, 2019
@OrangeDog
Copy link
Contributor Author

Any x509.certificate_managed state with ca_server, such as the documentation examples.

@Ch3LL
Copy link
Contributor

Ch3LL commented Mar 18, 2019

ping @clinta any chance you can take a look here? Are you seeing this same behavior?

@clinta
Copy link
Contributor

clinta commented Mar 19, 2019 via email

@th31nitiate

This comment was marked as off-topic.

@Ch3LL

This comment was marked as outdated.

@OrangeDog

This comment was marked as outdated.

@glynnforrest
Copy link
Contributor

Could this be related to #50734 (short tags vs long tags, e.g. CN vs commonName)?

@OrangeDog
Copy link
Contributor Author

@glynnforrest no, this issue is about it generating new certificates before it does any checks at all.

@glynnforrest
Copy link
Contributor

Right you are @OrangeDog, I should have looked at the code you linked before commenting.

I've ran into too many bugs with x509.certificate_managed (#39608, #41858) and need to keep moving before 2019.2.1 is released. I'm going to rewrite it as a custom state function.

@Ch3LL would you be interested in a PR that would significantly change the function code if it kept API compatibility and fixed the outstanding issues?

Either way, I will paste the function here when I've got it working.

@glynnforrest
Copy link
Contributor

Update: I've written a replacement with better error messages that's actually working quite well. I'm hoping to deploy it this week, confirm it solves the issues I've been facing, then submit a PR.

@OrangeDog
Copy link
Contributor Author

I just stopped using copypath to avoid the major issues with this.
If submitting a complete rewrite @glynnforrest then you may also want to look at my solution to #52180

glynnforrest added a commit to glynnforrest/salt that referenced this issue May 7, 2019
The function now displays clearer error messages when a problem occurs
and informative messages when comparing an existing certificate.

test=True is now supported.

It fixes the following errors:

* Certificate errors are written to the target file (saltstack#41858)
* New certificates are created every run (saltstack#52167)

The `managed_private_key` option has been removed due to the added
complexity. The functionality can easily be replicated with an
additional call to `x509.private_key_managed`. According to the comment
at saltstack#39608 (comment)
`managed_private_key` has not worked since at least v2016.11.2.
@glynnforrest
Copy link
Contributor

PR is in: #52935

@OrangeDog the rewrite changes how certificates are checked for updates so #52180 may not apply any more. I'd be grateful if you could try out the rewritten function!

@Ch3LL Ch3LL added Bug broken, incorrect, or confusing behavior fixed-pls-verify fix is linked, bug author to confirm fix severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around P3 Priority 3 and removed info-needed waiting for more info labels May 10, 2019
@Ch3LL Ch3LL modified the milestones: Blocked, Approved May 10, 2019
@stale

This comment was marked as outdated.

@stale stale bot added the stale label Jan 8, 2020
@OrangeDog
Copy link
Contributor Author

Still not resolved. PR is in progress.

@stale

This comment was marked as outdated.

@stale stale bot removed the stale label Jan 8, 2020
@iavael

This comment was marked as outdated.

@sagetherage sagetherage added this to the Silicon milestone Feb 9, 2021
@sagetherage sagetherage added phase-plan Silicon v3004.0 Release code name and removed phase-execute Aluminium Release Post Mg and Pre Si labels Feb 9, 2021
@OrangeDog
Copy link
Contributor Author

OrangeDog commented Feb 10, 2021

@sagetherage that would also be a good time to look at deduplicating between the tls and x509 states and modules.

@s0undt3ch
Copy link
Collaborator

@OrangeDog TCP and x509?
Sorry, on the phone so it's hard to look at the relationship on those.

@OrangeDog
Copy link
Contributor Author

@s0undt3ch whoops, sorry, TLS not TCP.

@sagetherage sagetherage assigned krionbsd and unassigned s0undt3ch Apr 20, 2021
@sagetherage sagetherage modified the milestones: Silicon, Approved Aug 12, 2021
@Ch3LL Ch3LL added the Sulfur v3006.0 release code name and version label Oct 25, 2021
@Ch3LL Ch3LL modified the milestones: Approved, Sulphur v3006.0 Oct 25, 2021
@Ch3LL Ch3LL removed the Silicon v3004.0 Release code name label Oct 25, 2021
@Ch3LL Ch3LL assigned s0undt3ch and unassigned krionbsd Oct 25, 2021
@dgengtek

This comment was marked as off-topic.

@OrangeDog
Copy link
Contributor Author

Just noting the additional irony of this comment

# We don't want generate a new certificate, even in memory,
# for security reasons.

given that it generates an additional cert every run, even in test mode (so twice if pre-requried x509.private_key_managed),

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior severity-high 2nd top severity, seen by most users, causes major problems
Projects
None yet
Development

Successfully merging a pull request may close this issue.