Varied CN field value in the certificate

security

(Andrew D) #1

Hi team,

In your documentation for the node certificate requirement, the CN field is said to be ‘node’. So I’m wondering if there would be any workaround for this? My organization has a strict security policy for signing certificate for any entity, so the CommonName has to be the hostname explicitly rather than simply ‘node’.

Thank you in advance!
Andrew


(Marc) #2

In 2.1 (currently in the release-candidate phase), you can specify separate client and server certificates for the node. The client certificate still needs to have CN=node, but the server certificate does not.

We are still putting the docs together, but you can find some details in this issue. One of the examples listed is pretty much your use case.


(Andrew D) #3

Hi Roacher, is there any timeline for the 2.1?


(Raphael 'kena' Poss) #4

Two weeks. Maybe four.


#5

Hi Marc,

I have a common question, in terms of certificate management identity of the certificate is basically the host to which the certificate is issued to. Even in case of client certificate the common name should be the hostname to which the certificate is issued to.

The hard coding of the common name to a “node” value will flag as a security vulnerability in case of security scanners as the common name does not match the hostname of the system and coach roach DB instance will be consuming the certificate.

Is there is way to relax this requirement for client certificate to have any name instead of “node” name.

Thank you for your reply in advance.

Regards
Anjali


(Marc) #6

When a certificate is used as a client certificate (either client.*.crt or node.crt for the node if we did not detect a separate client.node.crt), the username is what needs to be verified and is stored in CN.

When a certificate is used as a server certificate (only node.crt), the list of addresses and DNS names used to reach it must be in the CN or Subject Alternative Names field.

I agree with you that the dual-purpose node.crt is a little odd, which is why we’ve just added the possibility to split node certificates into server-side (node.crt) and client-side (client.node.crt).

However, the use of the CN to store a username for a client certificate is perfectly normal.

Furthermore, requiring the hostname (which one? in some of our deployments, there are up to 5 IP addresses or DNS names that can reach a node) to be in CN has been deprecated for ages. The hostname must be found in the combination of CN and Subject Alternative Names.


#7

Hi Marc,

The use case of using cockroach DB is that it is run on the system and is not user specific. So the certificate is not issued to a user, but to the system, so the common name is the hostname.

In our case, cockroach DB can be run on client and server systems, so the common name will always be the hostname of the system.

DNS IP will always be in the subject alternative name. We just want to relax the requirement of having “node” in the common name field so the certificate issued to the systems can be used by the cockroach DB. Is there a flag we can have to relax the requirement of having “node” as the common name while starting cockroach DB in secure mode using the system issued certificates.

Thanks
Anjali


(Marc) #8

There is currently no configuration for client certificates, the username must be located in the common name.
Furthermore, cockroachdb nodes must have CN=node. node is a special user and the only one allowed to perform certain actions (pretty much all node-to-node communication).

We have an issue filed to provide more flexibility in terms of 1) which field is used to store the username for client certificates, and 2) what the special user is, but it does not currently have an estimated milestone.

Please note that the requirement to have node as the user only applies to the CockroachDB nodes. All other clients need to put their SQL usernames, and it’s perfectly valid to have the a username be a hostname.


#9

Hi Marc,

In our use case, cockroach DB will be run as a server and a client and the certificates used for them will be the system certificates which has the common name as the hostname. The certificates are issued in a way to support scalable architecture.

The requirement of having the username as “node” in common name seems like a hard coded dependency which is restricting us to re-use the infrastructure we have and work more to support this requirement, and after having a security analysis of the usage, for certificate management the identity should be unique of the certificate (common name) nevertheless the fingerprint will be unique.

I request to please enhance the feature to have a any name as common name as it will add flexibility to the usage of secure communication through cockroach DB for backward compatibility if no name is provided “node” can be used as a default.

Just a humble 2 cents.

Thank you for your contribution and support!
Regards
Anjali