#4407 Improve OpenSSL config for RFC 5280 compliance (Python 3.13)
Closed by nines. Opened by nines.
nines/koji master  into  master

Download 4407.patch
  • Added critical keyUsage and extendedKeyUsage fields for client/server auth.
  • Marked basicConstraints and keyUsage critical in v3_ca profile.
  • Added v3_req profile with proper constraints and SAN support.
  • Defined alt_names section using $ENV::DNS_NAME for SAN.

1 new commit added

  • Add firewalld configuration setup

created https://pagure.io/koji/issue/4408

Metadata Update from @tkopecek:
- Pull-request tagged with: doc

At this point, I've generally been using koji-ssl-admin from koji-tools, to generate these certs. So I'm wonder if it might make more sense to update the docs to describe that instead.

The tools script relies on python-cryptography and doesn't involve an ssl.cnf file. It only invokes openssl directly to write out pkcs12. The rest is done through the library.

I suspect the tool already has sane defaults. That said, it hasn't been touched in a couple years, so I wonder if it needs any updates along these same lines.

WRT to the firewalld section. I think that is a useful addition, but it needs to be written in a less imperative way, and more as a suggestion for common deployment setups. Different setups might have different firewall needs.

Also, for the web ui we do not support python2, so I don't think there is much point in including the bit about rhel6.

@mikem I do agree that it's not the most elegant solution. It's more on the lines of a temporary patch so anyone who tries to deploy it on Fedora 42 and above, doesn't encounter failure on account of lacking documentation.

The firewalld section should have been a separate PR, but I pushed it without checking on branch so that's my bad.

Do you mind if I close this PR for now? We can discuss how the documentation can be updated to take a more modern approach.

Closing PR. Requires a more thorough discussion and planning to tackle the issue.

Pull-Request has been closed by nines

@mikem I'd appreciate your input on how to best approach this.
As you mentioned, using a tool like koji-ssl-admin would be more graceful way of handling it. But I am confused as to if that should be the only way to handle certs in the doc, or more of a supplementary method?

In the current iteration of the docs, not even the kojiadmin user would be able to communicate with the hub for the initial testing. So it is imperative that either the SSL config itself be updated to conform the standard, which is discussed in this PR, or just update the docs to just use the ssl-admin tool from the beginning.

Of course the doc modification could be completely avoided by updating the koji cli client app to disable the strict checking, see this, but that would be another issue.

Metadata