Fixes: https://pagure.io/koji/issue/1878
Metadata Update from @tkopecek: - Pull-request tagged with: no_qe
:thumbsup:
pretty please pagure-ci rebuild
There are many possible working variations for a kojihub httpd configuration. I'm not sure this is the optimal one.
Generally, the SSLVerifyClient, SSLVerifyDepth, and SSLOptions values are set in the appropriate <Location> blocks in the httpd config for kojihub and kojiweb, as shown in the example configs we ship. These settings are only required for a few urls, so they are very specific cases.
SSLVerifyClient
SSLVerifyDepth
SSLOptions
<Location>
OTOH, the SSLCertificate* values should normally be set globally in ssl.conf because they apply to the entire VirtualHost.
SSLCertificate*
Agreed with Mike that we should keep those SSLCertificate* settings in the VirtualHost level.
VirtualHost
By the way, I saw that this PR drops the references to TLSv1.2 vs TLSv1.3. This stood out to me because I found a regression in Ubuntu's recent TLSv1.3 backport to httpd mod_ssl on Bionic - more details at https://github.com/ktdreyer/koji-ansible/issues/114 . In my limited ad-hoc testing, it seems like Fedora clients and servers were fine with TLSv1.3 enabled in the httpd config now, but it made me think more about this.
The problem is that TLSv1.3 changes the way that SSLVerifyClient works within Apache's <Location> directive, and that whole feature is important to how Koji does SSL client authentication. The experience made me think that we should map out a full integration test matrix of "clients OS" authenticating to "server OS", since we are relying on several underlying pieces all working together there that slowly shift over time: OpenSSL, and Python, and urllib3, and python-requests, and Apache.
Proposed changes here: https://github.com/mikem23/koji-playground/commits/pagure/pr/2057
1 new commit added
Make the docs more in line with our example configs
Commit 1a9129c5 fixes this pull-request
Pull-Request has been merged by tkopecek
Fixes: https://pagure.io/koji/issue/1878