Hello Jochen,
Jochen Kellner [2021-10-11 23:06 +0200]:
> > For the TLS certificate, we recently had the idea that cockpit.service could
> > have a pre-start command that copies the certificate into /run/cockpit/ and
> > adjusts the permissions as necessary. That would make it a lot simpler (and
> > even possible) to share a certificate between multiple services, as
> > otherwise
> > one can never put correct permissions on the secret keys. The same scheme
> > would
> > actually work for the cockpit keytab. This is in our quarterly plan now
> > (https://issues.redhat.com/browse/COCKPIT-814 but sorry, that's internal).
>
> That works for regular starts. But - what if the keytab gets refreshed
> at runtime or an expired certificate gets refreshed? For the cert I'd
> like to see automatic refreshes...
Right, that's more tricky. It will use the new certificate as soon as nobody
has an active cockpit session any more, as then the webserver will just time
out and quit after a few seconds of inactivity. But of course if there is
always an overlapping succession of user sessions, this won't work. One could
play some tricks with a systemd path unit and such.
> >> For TLS the documentation says to generate the TLS certificate with
> >>
> >> getcert request -f ${CERT_FILE} -k ${KEY_FILE} -D $(hostname --fqdn) -C \
> >> "sed -n w/etc/cockpit/ws-certs.d/50-from-certmonger.cert ${CERT_FILE} \
> >> ${KEY_FILE}"
FTR, this is way too complicated these days.
> > Eek, thanks for reporting! I filed
> > https://github.com/cockpit-project/cockpit/issues/16450 about this, and
> > added
> > it to our current quarterly plan, this is quite important. The above schema
> > for
> > copying the cert to /run ought to take care of the reading permission
> > issues,
> > but of course certmonger needs to be able to write the cert in the first
> > place.
>
> Great! Thanks for opening the issue and tracking it.
I had a first stab at this in
https://github.com/cockpit-project/cockpit/pull/16453
I still need some help from our SELinux developers to fix the policy, but after
that this should work quite a bit better.
> >> I've used "-K cockpit/$(hostname --fqdn)" as a parameter to ipa-getcert,
> >> so the certificate is attached to that service. That way I have no
> >> conflict with host certificates or a certificate attached to the HTTP/
> >> principal. That way both the certificate and the keytab are attached to
> >> the same cockpit/ principal without interferring with HTTP/ services.
Nice!
Martin
_______________________________________________
cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org
To unsubscribe send an email to cockpit-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
