Add certs expiry params by ShimShtein · Pull Request #456 · theforeman/foremanctl

ShimShtein · 2026-04-19T15:08:04Z

Why are you introducing these changes? (Problem description, related links)

https://redhat.atlassian.net/browse/SAT-43479

We need to expose the certificate validity to the users, so it would be possible to align it with the local security policies.

What are the changes introduced in this pull request?

Created new ansible variables to parameterize the expiration date
Exposed the variables to the user through metadata.obsah.yaml

How to test this pull request

Steps to reproduce:

Run an installation procedure
Make sure to set custom expiration for each of the parameters
Validate the expiration of certificates

Checklist

Tests added/updated (if applicable)
Documentation updated (if applicable)

ShimShtein · 2026-04-19T15:40:13Z

@stejskalleos One thing I see already as a problem: the certs are not regenerated if I change the expiry date.

evgeni · 2026-04-20T06:11:55Z

That's quite intentional (see https://docs.ansible.com/projects/ansible/latest/collections/community/crypto/x509_certificate_module.html#parameter-selfsigned_not_after and https://docs.ansible.com/projects/ansible/latest/collections/community/crypto/x509_certificate_module.html#parameter-ownca_not_after) as otherwise the use of relative timestamps would mean that the cert is regenerated on every run.

evgeni · 2026-04-20T06:14:02Z

/packit build

ShimShtein · 2026-04-20T07:43:22Z

@evgeni should we switch to absolute timestamps then? Maybe it will make more sense to us, so we will be able to prolong the validity without too much hassle?

evgeni · 2026-04-20T07:48:03Z

My gut feeling is that it wouldn't make the UX any better, but I might have not thought is through completely.

ShimShtein · 2026-04-20T08:04:46Z

I would say that the client and server certs are safe to regenerate, which is not really possible without the option (unless we want to split it into a different feature).
For the CA it's a bit more problematic, since we will need to create a specific merged CA cert, distribute it and switch to a new one. I would vote not to allow the regeneration altogether (only by deleting the current cert).

evgeni · 2026-04-20T09:20:08Z

You don't want to regenerate certificates continuously. This will trigger service restarts, which users don't like. And also could have negative effects if people use certificate pinning or similar (based on the actual cert, not the CA, this is clearly "don't do it like this" territory, but often people don't listen to such advice). Also, this is kinda against the whole idea of certificate validity, as it just pushes it out "forever".

So we could either use absolute timestamps (which means we'd have to store them), or dynamically set ignore_timestamps=false when the user indicates they actually want to perform a certificate renewal?

ShimShtein · 2026-04-20T09:31:49Z

I was thinking about using absolute timestamps, as I said previously.
So what I thought was:

Use absolute timestamps for all three fields (ca, server, client)
Set the ignore_timestamps statically to false for server and client
Add a regenerate_ca flag that will control the ignore_timestamps for the CA field.

What do you think, would it make more sense? This way we enable easy change to the more common certs, and a confirmation flag to CA, that requires more attention from the user.

evgeni · 2026-04-20T09:43:48Z

In your setup, how would a user renew certificates that are bound to expire in (say) two weeks?

ShimShtein · 2026-04-20T10:16:59Z

If we are talking about server or client certs it would be running

foremanctl deploy --cert-server-validity 20-04-2027 --cert-client-validity 20-04-2027

But if the user wants to change the CA validity, then it would be something like

foremanctl deploy --cert-ca-validity 20-04-2027 --regenerate-ca

evgeni · 2026-04-20T10:25:48Z

Okay. And my alternative (for server/client) would be:
Define the validity once via foremanctl --certificate-days 7300
Renew at any time with foremanctl --certificate-renew
(Or whatever the names end up with, thats not important)

Does anyone else have an opinion/preference?

ekohl · 2026-04-20T11:02:34Z

I think a user wants minimal downtime and secure communication. For that we chose to use certificates and they need to be valid.

@evgeni already mentioned to avoid service restarts due to certificate changes, but downtime can also be caused by expired certificates.

How do we translate that into a process and parameters? You need to create a certificate and determine a validity period (measured in days). Then you also need to determine when to renew. That probably shouldn't be the validity period, otherwise you'll renew it all the time.

Let's Encrypt has proposed a process via RFC 9773. While I don't expect us to implement this right now, I like the idea and we can learn from the concepts. suggestedWindow jumps out to me: can we also determine this for our certificates?

A basic implementation to have a minimum validity period.

Define the validity once via foremanctl --certificate-days 7300

I like this.

Renew at any time with foremanctl --certificate-renew

I'm thinking of automating it and avoid introducing new parameters by using a formula. For example, take half the certificate_days but at most renew every 30 days: min(certificate_days / 2, 30).

I don't know if this also works for the CA or it needs a more nuanced implementation.

ShimShtein · 2026-04-20T14:37:44Z

If we will introduce a single --certificate-renew flag, we won't be able to manage separate validity periods. I would suggest having a parameter per certificate type (ca, client, server).
Specifically for the CA, the problem is that we need to distribute the new CA in a secure way (which means installing a dual CA for a while on the server, distributing the new CA to all the known clients and reinstalling the new CA on the server). I would argue that the CA renewal process should be handled by a separate command.
The problem with automation is not about regeneating the certs, it's about distributing those certs to the clients (smart proxies). This means keeping a list of all known hosts (we can derive it from the list of smart-proxies in Foreman) and orchestrating the upload of the certificates to those hosts.

evgeni · 2026-04-21T08:44:53Z

while I can see different validity for CA and non-CA, I see no reason to differentiate between server and client certs.

ShimShtein · 2026-04-21T11:10:57Z

I think I have addressed everything. How does it look now?

ekohl · 2026-04-21T11:22:32Z

Should we track the renewal in the same PR? I think there's a lot to discuss on that topic and I don't think we should hold up adding the expiration params on that.

evgeni · 2026-04-21T11:31:31Z

Should we track the renewal in the same PR? I think there's a lot to discuss on that topic and I don't think we should hold up adding the expiration params on that.

I think the current state is "good enough" to be used as a starting ground for any follow up discussions if needed (or to be ripped out, if we decide to go a different route).

evgeni · 2026-04-22T06:32:41Z

+    help: Lifetime of the generated server and client certificates, in days.
+    parameter: --certificate-validity-days
+  certificates_renew:
+    help: Remove and regenerate server and client certificates for each issued hostname (does not regenerate the CA).


Suggested change

help: Remove and regenerate server and client certificates for each issued hostname (does not regenerate the CA).

help: Regenerate server and client certificates for each issued hostname (does not regenerate the CA).

I'd start the last bit as a new sentence. Also questioning if the "for each issued hostname" is really relevant. How about:

Suggested change

help: Remove and regenerate server and client certificates for each issued hostname (does not regenerate the CA).

help: Force renewal of the server and client certificates. Does not regenerate the CA.

As we're adding custom certs in #462 and those would not be renewed by this, I wonder if there is a word we could use to differentiate the certs here. Something like "managed server and client certificates"? Doesn't have to be solved in this PR, but having clear wording which movable parts of the stack are "bring your own" and which are "we do it for you" would be cool.

The old default CA and server CA naming was really poor, but I struggle to come up with something better. Internal vs External perhaps?

"Force renewal of the server and client certificates issued by the internal CA."? Sounds cludgy.

What about Regenrate server and client certificates previously generated by foremanctl. Does not regenerate the CA.

Technically they are not regenerated (the private and public keys remain the same, only the signature changes), but I don't really mind.

ekohl · 2026-04-22T08:30:57Z

    ownca_privatekey_passphrase: "{{ certificates_ca_password }}"
-    ownca_not_after: "+7300d"
+    ownca_not_after: "+{{ certificates_validity_days }}d"
+    force: "{{ certificates_renew | bool }}"


IMHO here we see the real value of using community.crypto. With our hand crafted openssl statements this would have been a pain.

ehelms · 2026-04-23T13:48:04Z

 certificates_cnames: []
 certificates_algorithm_type: RSA
 certificates_algorithm_size: 4096
+# Validity periods in days (used as +Nd for community.crypto not_after).


A bit nitpicky here -- the variable name tells me this information already. And I do not understand the part in parenthesis to feel like it adds value.

ehelms

This is missing documentation updates and tests at least for the renew workflow.

ShimShtein · 2026-04-23T16:29:15Z

Updated the documentation, but couldn't understand how to properly add a test that will rerun the installer.

amolpati30 · 2026-04-24T13:43:52Z

+variables:
+  certificates_ca_validity_days:
+    help: Lifetime of the generated CA certificate, in days.
+    parameter: --certificate-ca-validity-days
+  certificates_validity_days:
+    help: Lifetime of the generated server and client certificates, in days.
+    parameter: --certificate-validity-days
+  certificates_renew:
+    help: Regenrate server and client certificates previously generated by foremanctl. Does not regenerate the CA.
+    parameter: --certificate-renew


If I set the expiration period for both the client and server certificates to 5 days each, my question is whether the customer will receive a notification before the certificates expire, as I do not see that happening here.

My second point is that --certificate-renew does not renew the CA certificate. If I set the CA certificate validity to 5 days, how will the CA certificate be renewed?

Also, you mentioned that the certificate is considered to have a lifetime. What exactly does that mean if I explicitly set its validity period to 5 days?

whether the customer will receive a notification before the certificates expire, as I do not see that happening here.

Is it something that we previously set up?

My second point is that --certificate-renew does not renew the CA certificate. If I set the CA certificate validity to 5 days, how will the CA certificate be renewed?

We have discussed it previously: CA renewal is a process and I want to treat it in a separate story.

Also, you mentioned that the certificate is considered to have a lifetime. What exactly does that mean if I explicitly set its validity period to 5 days?

I may be missing something, but if you set validity period to 5 days, it means that the lifetime of the certificate would be 5 days from the run of the module.

whether the customer will receive a notification before the certificates expire, as I do not see that happening here.

Is it something that we previously set up?

I guess no, i do not see in the old installer.

If the server and client certificates have expired and I want to renew them, will this work using this option?
foremanctl deploy --certificate-validity-days 365 --certificate-renew or
foremanctl deploy --certificate-renew

I tried renewing the expired server and client certificates, but it does not seem to be supported. Is it required to have a valid CA certificate first before renewing the server and client certificates?

foremanctl deploy --certificate-renew should be sufficient, in my understanding

was the CA expired too?

You can do both. In the shorter case, I guess you will be getting the default validity (7300 days). Unless @evgeni says that we preserve the validity days parameter by default.

Is it required to have a valid CA certificate first before renewing the server and client certificates?

Yes, the CA has to be valid. We are signing the server and client certs with the CA.

foremanctl deploy --certificate-renew should be sufficient, in my understanding

was the CA expired too?

Yes, the CA certificate has also expired.

You can do both. In the shorter case, I guess you will be getting the default validity (7300 days). Unless @evgeni says that we preserve the validity days parameter by default.

If you haven't marked it as persist: false, it will of course be preserved (which I think is the correct way to do it)

evgeni

wording nitpick, but otherwise ACK

ShimShtein · 2026-04-27T11:04:29Z

All the certs were fixed.

amolpati30

I have done below testing scenarios here to validate the certificates:

Verify that the default validity period is correctly applied to the certificates.

Explicitly set the certificate validity period, validate it, and then update the server and client certificate validity again using the --certificate-renew parameter, followed by validation.

ShimShtein added 2 commits April 19, 2026 17:22

Parameterize the expiry date

e5ce60d

Expose certificate lifetime to the user

57408c7

pr-processor Bot added the Not yet reviewed label Apr 19, 2026

stejskalleos self-assigned this Apr 20, 2026

Merge client and server cert validity

06396c8

evgeni reviewed Apr 21, 2026

View reviewed changes

Comment thread src/roles/certificates/tasks/issue.yml Outdated

pr-processor Bot removed the Not yet reviewed label Apr 21, 2026

evgeni reviewed Apr 21, 2026

View reviewed changes

Comment thread src/roles/certificates/tasks/issue.yml Outdated

evgeni reviewed Apr 21, 2026

View reviewed changes

Comment thread src/roles/certificates/tasks/issue.yml Outdated

ehelms reviewed Apr 21, 2026

View reviewed changes

Comment thread src/playbooks/_certificate_validity/metadata.obsah.yaml Outdated

ehelms reviewed Apr 21, 2026

View reviewed changes

Comment thread src/roles/certificates/tasks/issue.yml Outdated

ehelms reviewed Apr 21, 2026

View reviewed changes

Comment thread src/vars/default_certificates.yml Outdated

ehelms reviewed Apr 21, 2026

View reviewed changes

Comment thread src/vars/installer_certificates.yml Outdated

pr-processor Bot added the Waiting on contributor label Apr 22, 2026

evgeni reviewed Apr 22, 2026

View reviewed changes

ekohl reviewed Apr 22, 2026

View reviewed changes

Add renew flag

ab2ec71

ShimShtein force-pushed the add_certs_expiry_params branch from ab5155b to ab2ec71 Compare April 23, 2026 12:34

pr-processor Bot added Needs re-review and removed Waiting on contributor labels Apr 23, 2026

Remove redundant defaults

5e15694

pr-processor Bot removed the Needs re-review label Apr 23, 2026

ehelms reviewed Apr 23, 2026

View reviewed changes

ehelms requested changes Apr 23, 2026

View reviewed changes

pr-processor Bot added Waiting on contributor Needs re-review and removed Waiting on contributor labels Apr 23, 2026

ehelms reviewed Apr 23, 2026

View reviewed changes

Comment thread docs/user/certificates.md

pr-processor Bot removed the Needs re-review label Apr 23, 2026

evgeni reviewed Apr 24, 2026

View reviewed changes

Comment thread docs/user/certificates.md

evgeni reviewed Apr 24, 2026

View reviewed changes

Comment thread docs/user/certificates.md Outdated

amolpati30 reviewed Apr 24, 2026

View reviewed changes

ShimShtein force-pushed the add_certs_expiry_params branch from 8c8f3d7 to 77fee5f Compare April 26, 2026 12:52

evgeni reviewed Apr 27, 2026

View reviewed changes

Comment thread docs/user/certificates.md Outdated

evgeni approved these changes Apr 27, 2026

View reviewed changes

Improve documentation

3484cc6

ShimShtein force-pushed the add_certs_expiry_params branch from 77fee5f to 3484cc6 Compare April 27, 2026 10:15

ehelms approved these changes Apr 27, 2026

View reviewed changes

amolpati30 approved these changes Apr 28, 2026

View reviewed changes

evgeni merged commit acd6faf into theforeman:master Apr 28, 2026
18 of 20 checks passed

evgeni mentioned this pull request Apr 28, 2026

Add custom server certificate support #462

Open

2 tasks

	help: Remove and regenerate server and client certificates for each issued hostname (does not regenerate the CA).
	help: Regenerate server and client certificates for each issued hostname (does not regenerate the CA).

	help: Remove and regenerate server and client certificates for each issued hostname (does not regenerate the CA).
	help: Force renewal of the server and client certificates. Does not regenerate the CA.

Conversation

ShimShtein commented Apr 19, 2026

Why are you introducing these changes? (Problem description, related links)

What are the changes introduced in this pull request?

How to test this pull request

Checklist

Uh oh!

ShimShtein commented Apr 19, 2026

Uh oh!

evgeni commented Apr 20, 2026

Uh oh!

evgeni commented Apr 20, 2026

Uh oh!

ShimShtein commented Apr 20, 2026

Uh oh!

evgeni commented Apr 20, 2026

Uh oh!

ShimShtein commented Apr 20, 2026

Uh oh!

evgeni commented Apr 20, 2026

Uh oh!

ShimShtein commented Apr 20, 2026

Uh oh!

evgeni commented Apr 20, 2026

Uh oh!

ShimShtein commented Apr 20, 2026

Uh oh!

evgeni commented Apr 20, 2026

Uh oh!

ekohl commented Apr 20, 2026

Uh oh!

ShimShtein commented Apr 20, 2026

Uh oh!

evgeni commented Apr 21, 2026

Uh oh!

ShimShtein commented Apr 21, 2026

Uh oh!

ekohl commented Apr 21, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

evgeni commented Apr 21, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ehelms left a comment

Choose a reason for hiding this comment

Uh oh!

ShimShtein commented Apr 23, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

amolpati30 Apr 27, 2026 •

edited

Loading

ShimShtein Apr 27, 2026 •

edited

Loading

evgeni Apr 27, 2026 •

edited

Loading