cephadm: truncate X.509 Common Name to 64 chars in generate_cert - #71407
Open
joshjan20 wants to merge 1 commit into
Open
cephadm: truncate X.509 Common Name to 64 chars in generate_cert#71407joshjan20 wants to merge 1 commit into
joshjan20 wants to merge 1 commit into
Conversation
The Common Name (CN) field in the certificate subject is limited to 64 characters per RFC 5280. generate_cert() previously passed the raw address/hostname directly as the CN with no length check. On cloud providers with long auto-assigned FQDNs (e.g. Google Cloud Platform, which embeds the project ID into every VM hostname), this can easily exceed 64 characters, causing certificate signing to fail with an opaque low-level error: asn1 encoding routines: ... string too long This surfaces to the user as an unexplained failure to deploy services that require a generated certificate (e.g. Grafana), with no indication that hostname length is the actual cause. TLS hostname verification relies on the SAN (Subject Alternative Name) list, not the CN. The full, untruncated hostname is already present in the SAN, added separately in this same method. Truncating only the CN when it exceeds 64 characters therefore has no effect on certificate validity or hostname verification; it only avoids the signing failure. Adds regression tests covering: the long-FQDN case no longer raising, the full FQDN remaining present in the SAN after truncation, short hostnames being left unmodified, and truncation landing at exactly 64 characters when it does occur. Signed-off-by: joshjan20 <joshjan20@gmail.com>
|
Thank you for your contribution. Since you are not yet a member of the Ceph organization with write permissions on ceph/ceph.git, our CI will not automatically run. Any member of the Ceph organization may label this PR |
14 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Common Name (CN) field in the certificate subject is limited to 64 characters per RFC 5280. generate_cert() previously passed the raw address/hostname directly as the CN with no length check. On cloud providers with long auto-assigned FQDNs (e.g. Google Cloud Platform, which embeds the project ID into every VM hostname), this can easily exceed 64 characters, causing certificate signing to fail with an opaque low-level error:
asn1 encoding routines: ... string too long
This surfaces to the user as an unexplained failure to deploy services that require a generated certificate (e.g. Grafana), with no indication that hostname length is the actual cause.
TLS hostname verification relies on the SAN (Subject Alternative Name) list, not the CN. The full, untruncated hostname is already present in the SAN, added separately in this same method. Truncating only the CN when it exceeds 64 characters therefore has no effect on certificate validity or hostname verification; it only avoids the signing failure.
The fix truncates the CN to 64 characters when needed. This does not affect certificate validity or TLS hostname verification, which relies on the SAN (Subject Alternative Name) list, not the CN; the full, untruncated hostname remains present in the SAN, unmodified.
Adds regression tests covering: the long-FQDN case no longer raising, the full FQDN remaining present in the SAN after truncation, short hostnames being left unmodified, and truncation landing at exactly 64 characters when it does occur.
Includes 4 regression tests, verified passing locally in a standalone environment (see commit message for details); full test suite integration will run via CI once labeled.
Contribution Guidelines
To sign and title your commits, please refer to Submitting Patches to Ceph.
If you are submitting a fix for a stable branch (e.g. "quincy"), please refer to Submitting Patches to Ceph - Backports for the proper workflow.
When filling out the below checklist, you may click boxes directly in the GitHub web UI. When entering or editing the entire PR message in the GitHub web UI editor, you may also select a checklist item by adding an
xbetween the brackets:[x]. Spaces and capitalization matter when checking off items this way.Checklist
Show available Jenkins commands
jenkins test classic perfJenkins Job | Jenkins Job Definitionjenkins test crimson perfJenkins Job | Jenkins Job Definitionjenkins test signedJenkins Job | Jenkins Job Definitionjenkins test make checkJenkins Job | Jenkins Job Definitionjenkins test make check arm64Jenkins Job | Jenkins Job Definitionjenkins test submodulesJenkins Job | Jenkins Job Definitionjenkins test dashboardJenkins Job | Jenkins Job Definitionjenkins test dashboard cephadmJenkins Job | Jenkins Job Definitionjenkins test apiJenkins Job | Jenkins Job Definitionjenkins test docsReadTheDocs | Github Workflow Definitionjenkins test ceph-volume allJenkins Jobs | Jenkins Jobs Definitionjenkins test windowsJenkins Job | Jenkins Job Definitionjenkins test rook e2eJenkins Job | Jenkins Job DefinitionYou must only issue one Jenkins command per-comment. Jenkins does not understand
comments with more than one command.