adding a new feature set for Public ACME servers #4244
Conversation
Signed-off-by: Arsh Sharma <arshsharma461@gmail.com>
jetstack-bot
added
do-not-merge/work-in-progress
|
Hi @RinkiyaKeDad. Thanks for your PR. I'm waiting for a jetstack or cert-manager member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
jetstack-bot
added
needs-ok-to-test
Signed-off-by: Arsh Sharma <arshsharma461@gmail.com>
RinkiyaKeDad
changed the title
jetstack-bot
removed
the
do-not-merge/work-in-progress
|
|
||
| // LongDomainFeatureSet denotes whether the target issuer is able to sign | ||
| // a certificate that defines a long domain | ||
| LongDomainFeatureSet Feature = "LongDomain" |
There was a problem hiding this comment.
What is a LongDomain in this context? (i.e. how long?) - I'd have assumed all our issuers should be able to sign for any domain that is within the length restrictions noted in RFCs.
| @@ -795,7 +795,7 @@ func (s *Suite) Define() { | |||
| By("Sanity-check the issued Certificate") | |||
| err = f.Helper().ValidateCertificate(f.Namespace.Name, "testcert", validations...) | |||
| Expect(err).NotTo(HaveOccurred()) | |||
| }, featureset.OnlySAN) | |||
There was a problem hiding this comment.
Ah, I see here that 'LongDomain' is defined as something that contains a subdomain segment that is maxLengthOfDomainSegment long (which I think is 63 characters) - I don't think any public ACME servers/Let's Encrypt's staging environment has a restriction on this? 🤔 if it does, and the 'pebble' based ACME server does not, then Pebble needs modifying to also fail in these cases as it aims to replicate the ACME RFC as closely as possible
There was a problem hiding this comment.
The issue is with Let's Encrypt specifically rather than the ACME protocol. There's a discussion here: certbot/certbot#1915
Let's encrypt copies one of the names from the subject alternative name (which supports arbitrary length domains) to the Common Name field (which is useless in modern TLS). Unfortunately, this field has a maximum length of 64 chars (C definition, so bytes).
This isn't a problem with cert-manager as we don't set the subject CN at all
|
/ok-to-test |
jetstack-bot
added
ok-to-test
and removed
needs-ok-to-test
Signed-off-by: Arsh Sharma <arshsharma461@gmail.com>
Signed-off-by: Arsh Sharma <arshsharma461@gmail.com>
Signed-off-by: Arsh Sharma <arshsharma461@gmail.com>
|
/lgtm |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jakexks, RinkiyaKeDad The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
jetstack-bot
added
the
approved
|
/kind feature |
jetstack-bot
added
the
kind/feature
jetstack-bot
removed
the
needs-kind
Signed-off-by: Arsh Sharma arshsharma461@gmail.com
What this PR does / why we need it:
Which issue this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close that issue when PR gets merged): fixes #Special notes for your reviewer:
Release note: