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 - httpd-init.service fails with long hostname (>=42)
Summary: httpd-init.service fails with long hostname (>=42)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sscg
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-17 15:13 UTC by Lukas Slebodnik
Modified: 2018-02-06 13:17 UTC (History)
5 users (show)

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:
Clone Of:
Environment:
Last Closed: 2018-02-06 10:51:48 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Lukas Slebodnik 2018-01-17 15:13:55 UTC 
Description of problem:


Version-Release number of selected component (if applicable):
sh$ rpm -q httpd mod_ssl sscg
httpd-2.4.29-1.fc27.x86_64
mod_ssl-2.4.29-1.fc27.x86_64
sscg-2.3.0-1.fc27.x86_64

How reproducible:
Deterministic

Steps to Reproduce:
0. rm -f /etc/pki/tls/private/localhost.key /etc/pki/tls/certs/localhost.crt
1. dnf install -y httpd mod_ssl -e 0 -d 0
2. hostname a23456789.b23456789.c23456789.d23456789.eu
3. systemctl start httpd (or just systemctl start httpd-init.service)

Actual results:
sh# systemctl start httpd-init.service
Job for httpd-init.service failed because the control process exited with error code.
See "systemctl status httpd-init.service" and "journalctl -xe" for details.
sh# systemctl status httpd-init.service
● httpd-init.service - One-time temporary TLS key generation for httpd.service
   Loaded: loaded (/usr/lib/systemd/system/httpd-init.service; static; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2018-01-17 10:10:51 EST; 37s ago
     Docs: man:httpd-init.service(8)
  Process: 1911 ExecStart=/usr/libexec/httpd-ssl-gencerts (code=exited, status=5)
 Main PID: 1911 (code=exited, status=5)

Jan 17 10:10:29 a23456789.b23456789.c23456789.d23456789.eu systemd[1]: Starting One-time temporary TLS key generation for httpd.service...
Jan 17 10:10:51 a23456789.b23456789.c23456789.d23456789.eu httpd-ssl-gencerts[1911]: Error occurred in X509_NAME_add_entry_by_NID (CN): [error:0D07A097:asn1 encoding routines:ASN1_mbstrin
Jan 17 10:10:51 a23456789.b23456789.c23456789.d23456789.eu httpd-ssl-gencerts[1911]: Input/output error
Jan 17 10:10:51 a23456789.b23456789.c23456789.d23456789.eu systemd[1]: httpd-init.service: Main process exited, code=exited, status=5/NOTINSTALLED
Jan 17 10:10:51 a23456789.b23456789.c23456789.d23456789.eu systemd[1]: httpd-init.service: Failed with result 'exit-code'.
Jan 17 10:10:51 a23456789.b23456789.c23456789.d23456789.eu systemd[1]: Failed to start One-time temporary TLS key generation for httpd.service.

Expected results:
sh# systemctl start httpd-init.service
sh# echo $?
0

Additional info:
Maybe a little bit simpler reproducer directly with sscg
sh# export STRING=a23456789.b23456789.c23456789.d23456789.eu
sh# sscg -q --cert-file /etc/pki/tls/certs/localhost.crt --cert-key-file /etc/pki/tls/private/localhost.key --ca-file /etc/pki/tls/certs/localhost.crt --lifetime 365 --hostname $STRING --email root@$STRING
Error occurred in X509_NAME_add_entry_by_NID (CN): [error:0D07A097:asn1 encoding routines:ASN1_mbstring_ncopy:string too long].
Input/output error
Comment 1 Joe Orton 2018-01-23 15:45:59 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
Comment 2 Stephen Gallagher 2018-01-24 09:45:11 UTC 
(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?
Comment 3 Joe Orton 2018-01-25 10:53:01 UTC 
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?
Comment 4 Stephen Gallagher 2018-01-25 11:16:29 UTC 
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.
Comment 5 Lukas Slebodnik 2018-01-25 13:46:26 UTC 
(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 */
Comment 7 Stephen Gallagher 2018-01-25 15:33:39 UTC 
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.
Comment 8 Fedora Update System 2018-01-25 16:06:48 UTC 
sscg-2.3.2-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-6c8dcd589d
Comment 9 Fedora Update System 2018-01-25 16:06:57 UTC 
sscg-2.3.2-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d8ab83f203
Comment 10 Fedora Update System 2018-01-25 16:07:03 UTC 
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
Comment 11 Fedora Update System 2018-01-26 19:12:07 UTC 
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
Comment 12 Fedora Update System 2018-01-26 19:49:27 UTC 
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
Comment 13 Fedora Update System 2018-01-26 20:28:28 UTC 
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
Comment 14 Joe Orton 2018-01-27 07:58:22 UTC 
LGTM, thanks a lot Stephen!
Comment 15 Fedora Update System 2018-01-30 18:07:35 UTC 
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.
Comment 16 Fedora Update System 2018-02-02 18:18:19 UTC 
sscg-2.3.3-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9d886c95d4
Comment 17 Fedora Update System 2018-02-02 18:18:25 UTC 
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
Comment 18 Fedora Update System 2018-02-04 19:38:11 UTC 
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
Comment 19 Fedora Update System 2018-02-04 20:02:02 UTC 
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
Comment 20 Fedora Update System 2018-02-06 10:51:48 UTC 
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.
Comment 21 Fedora Update System 2018-02-06 13:17:48 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.