KSSL: Add Let's Encrypt certificates support #150

Merged
blu.256 merged 2 commits from feat/kssl-letsencrypt into master 4 months ago
blu.256 commented 4 months ago
Collaborator
  • Commit d0e22f49b3 adds the two root certificates of ISRG, which are used to sign the Let's Encrypt certificates, per https://letsencrypt.org/certificates/.
  • Commit b379252791 contains changes performed by running the mergelocal script to merge "local" (i.e. non-Netscape) pem certificates. Except for including the two certificates mentioned above, it also seems to have added several more certificates which apparently were present but not bundled.

Tested with Konqueror for HTTPS.

* Commit d0e22f49b3 adds the two root certificates of ISRG, which are used to sign the Let's Encrypt certificates, per https://letsencrypt.org/certificates/. * Commit b379252791 contains changes performed by running the `mergelocal` script to merge "local" (i.e. non-Netscape) pem certificates. Except for including the two certificates mentioned above, it also seems to have added several more certificates which apparently were present but not bundled. Tested with Konqueror for HTTPS.
blu.256 added 2 commits 4 months ago
d0e22f49b3
KSSL: Added ISRG root certs for LetsEncrypt
b379252791
KSSL: Rebuilt local certificates bundle
blu.256 added this to the R14.0.12 release milestone 4 months ago
blu.256 added the
PR/rfc
label 4 months ago
Owner

Adding the additional certificates is a good step forward. I wonder how the additional entries in tdeio/kssl/kssl/ksslcalist where chosen. I was a bit surprised there are so many new entries for only two new certificates.

A side now to this PR, bug 2785 highlight a suggestion for automatic updating the ksslcalist file. I think we should look into the idea and see how to make use of that. Rather than overwriting /etc/trinity/ksslcalist, we should update tdeio/kssl/kssl/ksslcalist and then build the package. It could even be a manual update once or twice a year.
What do you think?

Adding the additional certificates is a good step forward. I wonder how the additional entries in tdeio/kssl/kssl/ksslcalist where chosen. I was a bit surprised there are so many new entries for only two new certificates. A side now to this PR, bug 2785 highlight a suggestion for automatic updating the ksslcalist file. I think we should look into the idea and see how to make use of that. Rather than overwriting /etc/trinity/ksslcalist, we should update tdeio/kssl/kssl/ksslcalist and then build the package. It could even be a manual update once or twice a year. What do you think?
Poster
Collaborator

I was a bit surprised there are so many new entries for only two new certificates.

As I mentioned I think these are certificates that were not merged (maybe forgotten?) that were already in the source tree (correct me if I'm wrong on this).

A side now to this PR, bug 2785 highlight a suggestion for automatic updating the ksslcalist file.

That would be better than having to update the file manually. Maybe we could also arrange to install and expose the certificates update script so that the list can be rebuilt manually without having to rebuild the whole package.

> I was a bit surprised there are so many new entries for only two new certificates. As I mentioned I think these are certificates that were not merged (maybe forgotten?) that were already in the source tree (correct me if I'm wrong on this). > A side now to this PR, bug 2785 highlight a suggestion for automatic updating the ksslcalist file. That would be better than having to update the file manually. Maybe we could also arrange to install and expose the certificates update script so that the list can be rebuilt manually without having to rebuild the whole package.
Owner

As I mentioned I think these are certificates that were not merged (maybe forgotten?) that were already in the source tree (correct me if I'm wrong on this).

Ok, thanks for the explanation.

That would be better than having to update the file manually. Maybe we could also arrange to install and expose the certificates update script so that the list can be rebuilt manually without having to rebuild the whole package.

Yes, it's a good idea. It also makes sure the file is updated based on what is on the user computer rathen than what is on the build computer.

> As I mentioned I think these are certificates that were not merged (maybe forgotten?) that were already in the source tree (correct me if I'm wrong on this). Ok, thanks for the explanation. > That would be better than having to update the file manually. Maybe we could also arrange to install and expose the certificates update script so that the list can be rebuilt manually without having to rebuild the whole package. Yes, it's a good idea. It also makes sure the file is updated based on what is on the user computer rathen than what is on the build computer.
Owner

The ideas mentioned here exactly correspond to the original idea. I assume that we will have two levels of updates:

  1. Within the steps of finalization before release, we can update the list of certificates for root authorities, which is part of the source code. This can serve as a basis and for systems where there is no central method of updating the list of certificates for root authorities.

  2. Create distribution-specific scripts that will update the list based on the current list of certificates for root authorities in distribution on user computer. This is an idea in bug 2785. These scripts belong to tde-packaging.

The ideas mentioned here exactly correspond to the original idea. I assume that we will have two levels of updates: 1. Within the steps of finalization before release, we can update the list of certificates for root authorities, which is part of the source code. This can serve as a basis and for systems where there is no central method of updating the list of certificates for root authorities. 2. Create distribution-specific scripts that will update the list based on the current list of certificates for root authorities in distribution on user computer. This is an idea in [bug 2785](https://bugs.trinitydesktop.org/show_bug.cgi?id=2785). These scripts belong to tde-packaging.
Poster
Collaborator

This can serve as a basis and for systems where there is no central method of updating the list of certificates for root authorities.

What would be an example of such a system? Many seem to have a package called ca-certificates.

> This can serve as a basis and for systems where there is no central method of updating the list of certificates for root authorities. What would be an example of such a system? Many seem to have a package called `ca-certificates`.
Owner

This can serve as a basis and for systems where there is no central method of updating the list of certificates for root authorities.

What would be an example of such a system? Many seem to have a package called ca-certificates.

For example, I do not know whether FreeBSD provides the ability to set our own hook script responding to a system certificates change.

> > This can serve as a basis and for systems where there is no central method of updating the list of certificates for root authorities. > > What would be an example of such a system? Many seem to have a package called `ca-certificates`. For example, I do not know whether FreeBSD provides the ability to set our own hook script responding to a system certificates change.
SlavekB approved these changes 4 months ago
SlavekB left a comment
Owner

I think we can merge this as it is now (after rebase to current head) and then separately prepare update scripts for hooks in distributions.

I think we can merge this as it is now (after rebase to current head) and then separately prepare update scripts for hooks in distributions.
Owner

I think we can merge this as it is now (after rebase to current head) and then separately prepare update scripts for hooks in distributions.

Yes, I think it is a good idea.

> I think we can merge this as it is now (after rebase to current head) and then separately prepare update scripts for hooks in distributions. Yes, I think it is a good idea.
blu.256 force-pushed feat/kssl-letsencrypt from b379252791 to 49ea1c8db2 4 months ago
blu.256 merged commit 49ea1c8db2 into master 4 months ago
blu.256 deleted branch feat/kssl-letsencrypt 4 months ago
blu.256 removed the
PR/rfc
label 4 months ago

Reviewers

SlavekB approved these changes 4 months ago
The pull request has been merged as 49ea1c8db2.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.