Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CN maxlength vs. empty CN vs. boulder #336

Open
icing opened this issue Jan 6, 2021 · 3 comments
Open

CN maxlength vs. empty CN vs. boulder #336

icing opened this issue Jan 6, 2021 · 3 comments

Comments

@icing
Copy link
Contributor

icing commented Jan 6, 2021

I added a test in mod_md for domain names longer than 63 octets. I see different behaviour between pebble and boulder. This is not an issue per se, I can slip these tests against pebble. However, I would prefer for pebble to react on this boundary condition.

When the 'first' domain is 64 octets or longer, mod_md leaves the CN in the CSR unspecified and relies on the ACME CA to either choose one or deny the request. boulder will - at least currently. look at all SAN names for one that is short enough. Then it issues the cert with that, otherwise it fails.

This is exactly what I test now. And this test fails against pebble as it seems happy to issue a certificate in either case. If I can configure pebble to behave differenlty here, please let me know. Thanks!

@jsha
Copy link
Contributor

jsha commented Jan 6, 2021

It looks like Pebble just doesn't have a check for max CN length. I would support adding that, and would accept a PR. My ideal in that situation would be for Pebble in that case to issue the certificate with an empty Subject and SANs critical. Boulder doesn't do that today, but it might someday, and it's the more correct thing to do IMO.

It sounds like that might not meet your needs, though, since you have tests that expect the CA to return error when all domain names are longer than 63 octets. I would say that's CA-specific behavior and probably should not be enforced by mod_md. Maybe I'm missing something. What's the behavior in mod_md these tests are trying to verify?

@icing
Copy link
Contributor Author

icing commented Jan 11, 2021

I had an issue raised about mod_md handling domains longer than 63 octets. I no longer populate the CN in the CSR for such domains and leave it up to the CA to decide what to do about it.

Atm, versus boulder, it expects a certificate to be handed out if one of the SAN names is short enough and a fail otherwise. I am not keen on nailing the CA to a specific outcome here, more interested to check that the module does the right thing.

There are two aspects of this test relevant for the module itself:

  1. Does it leave the CN empty in such a case and get a certitificate if one name is <64?
  2. If the CA refuses (currently when no name is short enough in boulder), how does the module handle the error?

I have no problem to differentiate server types here. There are not that many servers to test against...

@jsha
Copy link
Contributor

jsha commented Jan 11, 2021

Sounds good. Another thing I've long envisioned for Pebble: A way to tell Pebble "please error on the next call to endpoint X." So you could for instance ask it to error on the next issuance call even if it doesn't have the Boulder-matching logic to reject requests that don't have at least one name <64 octets.

So to wrap up:

  • There's no way to configure Pebble to reject requests without at least one name < 64 octets, and I'd prefer not to add it.
  • I'm interested in adding some validation of CN in Pebble on general correctness grounds.
  • I'm also interested in adding "please reject X request" hooks.
  • But neither of the above is a particular priority right now; if it would make life significantly better for you though, please let us know and we'll reconsider!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants