vic-ui
vic-ui copied to clipboard
vmware
VCH name is used as default common name in auto-generated certs
VIC version:
vic-dev-2867-v1.3.0-rc4-2867-f8cc7317.ova
Deployment details:
Deploying VCH from Create VCH wizard
Steps to reproduce:
Progress through wizard to security page.
Actual behavior:
The Common Name (CN) field is pre-populated with the name of the VCH:
Expected behavior:
According to the CLI doc and the vic-machine create help, as well as the tip in the UI, the value for the --tls-cname option should be an IP, FQDN or domain wildcard for the client system from which you are going to run Docker commands against this VCH. Presumably (I haven't tested this) if you upload a custom CA, then some field in the custom CA must match the common name that you insert here. If you leave the default value of the VCH name, won't there be a certificate mismatch if you upload a custom CA? Or does this not matter? If something in the CA that you upload must correspond to the CN in the auto-generated server cert, then wouldn't it be better to leave the Common Name field blank by default?
Actually, rereading both this issue and my own doc for --tls-ca, the CA for client certs is/can be completely independent of the server cert. In this case, if you cannot use an auto-generated client cert or CA with the UI, can the CN for an auto-generated server cert basically be anything at all? Can someone who knows better than me please confirm this?
@hickeng can you weigh in here and let us know if you feel like this is a valid concern/issue? It's not clear to me if this would cause any issue.
@jak-atx
The tls-cname should not be set to the "name" of the VCH. It should be left blank or set to one of the values the doc specifies. Setting this field causes it to override the default values that would have been entered into the certificate for IP/FQDN derived from the IP and a reverse name lookup.
We use the tls-cname option as both the CN field AND as the subjectAltName DNS record entry. If combined with a static IP address this actually overrides the SAN IP entries that we would create.
This is only relevant if generating certificates for full TLSVERIFY (clients have to authenticate) - if using no-tlsverify then the names really don't matter, but should still be consistent with the correct setup.
Note to self: RFC 6125 updates the certificate validation so that it should check the subjectAltName fields first for the address used to access the host and only check CommonName if there's no match in the SANs.
@hickeng and @jak-atx, if this is not going to be fixed in 1.4, do I need to add something in the doc to tell people to remove the default VCH name from that field?
The field appears to be marked as required, so I don't think clearing the value is an option.
This seems to be higher priority than it's currently labeled, but perhaps I've misunderstood the user-facing impact.
