Est limitation #4982
Est limitation #4982
Conversation
The new option "enrollMatchTLSSubjSAN" default to true so the check is always performed. If disabled, users can add their checks in the authorizer executable since the information for the match (CSR and cleint cert chain) are provided.
There was a problem hiding this comment.
For the record, since this is a "stopgap" patch due to close release time, only need to address the minor comments on error messages.
I'll create a new "phase 2" ticket for a potentially more proper fix where Fraser could add ideas since he has more knowledge with the rfc.
| try { | ||
| cert = new X509CertImpl(cert_.getEncoded()); | ||
| } catch (CertificateException e) { | ||
| throw new ForbiddenException("Failed to decode certificate to be renewed."); |
There was a problem hiding this comment.
the method ensureCSRMatchesToBeCert intends to be used for renew or new enrollment, so you want to watch for the messages there. In the case, you don't know if the cert is for renewing or not.
| throw new ForbiddenException( | ||
| "SAN extensions of certificate to be renewed and CSR are not identical."); | ||
| } | ||
| } else if (csrSAN == null && certSAN != null && renew) { |
There was a problem hiding this comment.
This is under the assumption that the profile on the CA will add the right SAN. Later when we add constraint on CA side to do the check it should be clear. Thought you might want to add a comment. Or, if want to avoid the confusion, just do the same for both and require them to be exactly the same.
There was a problem hiding this comment.
If there is a check on the SAN the CSR has to have the provided SAN or no SAN. I do not see this dependent on the CA policy.
There was a problem hiding this comment.
Yeah to do that, the CommonNameToSANDefault policy needs to be added to the est profile, if desired. Let's just do whatever is easiest now.
There was a problem hiding this comment.
This policy is included in default policy.
| ); | ||
| } else if (csrSAN != null && certSAN == null) { | ||
| throw new ForbiddenException( | ||
| "Certificate to be renewed does not have SubjectAlternativeName extension, " |
There was a problem hiding this comment.
again, the seems to apply to both renew and new enrollment. The message is misleading.
| @@ -142,3 +142,14 @@ $ curl --cacert ./ca_signing.crt --cert cert.pem --key key-x-x.pem \ | |||
| --data-binary @testServer.p10 -H "Content-Type: application/pkcs10" | |||
| -o newCert.p7 https://<EST_HOSTNAME>:<EST_PORT>/.well-known/est/simpleenroll | |||
| ---- | |||
|
|
|||
There was a problem hiding this comment.
I just want to add that for phase 2, when the constraint is done on the CA side, we'll also allow a CA agent to submit the request using their agent cert that doesn't have to match the dn/san in the CSR. I'll put that in a "phase 2" ticket.
If EST client uses basic authentication the CSR subject common name and SAN, if present, have to match with the user full name or the user uid. The check can vi disabled using the option "enrollMatchTLSSubjSAN" set to false in the authorizer.conf file.
|
No description provided.