Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1535537
Summary: | httpd-init.service fails with long hostname (>=42) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Lukas Slebodnik <lslebodn> |
Component: | sscg | Assignee: | Stephen Gallagher <sgallagh> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 27 | CC: | jkaluza, jorton, luhliari, pahan, sgallagh |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | sscg-2.3.2-1.fc27 sscg-2.3.3-1.fc26 sscg-2.3.3-1.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-02-06 10:51:48 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Lukas Slebodnik
2018-01-17 15:13:55 UTC
We had this workaround in the old mod_ssl %post, Stephen I think we should solve this in sscg too (somehow)? FQDN=`hostname` if [ "x${FQDN}" = "x" -o ${#FQDN} -gt 59 ]; then FQDN=localhost.localdomain fi (In reply to Joe Orton from comment #1) > We had this workaround in the old mod_ssl %post, Stephen I think we should > solve this in sscg too (somehow)? > > FQDN=`hostname` > if [ "x${FQDN}" = "x" -o ${#FQDN} -gt 59 ]; then > FQDN=localhost.localdomain > fi Hmm, searching around a bit, it looks like the CN field has a maximum length of 63 characters in the x509 spec, but subjectAlternativeName is allowed to be much longer (some places say 255). Browsers now are required to validate using SANs instead of the CN, so it shouldn't be too much of an issue to just set the hostname to 'localhost.localdomain' if the provided value would be longer than supported. In SSCG, we actually end up with a slightly shorter limit for the hostname because the one-time CA that it creates prepends the hostname with `ca-$SERIAL` for the Common Name portion of the Subject. As a result, that reduces the usable length of the hostname to 45 characters. I think what I may do is change the temporary CA to put the unique serial into one of the other Subject fields (org-unit?) so we can get back to supporting 63-character hostnames. I'll then do what I said above for both the CA and service certificates if the hostname exceeds 63 chars. Does that seem like a reasonable plan? Makes sense to me, +1. Maybe could skip putting the CN into the cert entirely as an alternative if it's too long, and just write the SAN in that case? This may take a bit longer to fix. I have code ready for SSCG that will do what we said above, but while testing it I have identified a bug in Firefox's x509 handling that causes it to fail to parse the CA certificate (if imported) because it doesn't like having >63 characters in the CA's nameConstraint for the host. (RFC 5280 requires it to handle anything that fits in subjectAlternativeName, so it's a clear bug). I'm working with them to fix that before I push this out. I'd rather have SSCG fail to create a certificate than create one that is known not to work on a popular browser. Though, it also turns out that if we just set `--subject-alt-name=veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylong.domain` today, it will also produce a CA cert that's incompatible with Firefox. So neither answer is ideal. (In reply to Stephen Gallagher from comment #4) > This may take a bit longer to fix. I have code ready for SSCG that will do > what we said above, but while testing it I have identified a bug in > Firefox's x509 handling that causes it to fail to parse the CA certificate > (if imported) because it doesn't like having >63 characters in the CA's > nameConstraint for the host. IIRC it is not possible to have longer hostname as 63 characters. So such limit should be sufficient. /usr/include/asm-generic/param.h:17:#define MAXHOSTNAMELEN 64 /* max length of hostname */ OK, I opted to fix the CA Subject to use Org Unit for the CA serial and to check the length of hostnames and SANs to disallow results longer than 64 characters in the hostname portion. SSCG will now give a clean error message and exit instead of leaking the OpenSSL internal error. It will also support the full 64 character hostnames. I will get a build out for this shortly. sscg-2.3.2-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-6c8dcd589d sscg-2.3.2-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d8ab83f203 sscg-2.3.2-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7aa08b322e sscg-2.3.2-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-d8ab83f203 sscg-2.3.2-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-6c8dcd589d sscg-2.3.2-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7aa08b322e LGTM, thanks a lot Stephen! sscg-2.3.2-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. sscg-2.3.3-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9d886c95d4 sscg-2.3.3-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ed2aea0295 sscg-2.3.3-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ed2aea0295 sscg-2.3.3-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-9d886c95d4 sscg-2.3.3-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. sscg-2.3.3-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report. |