What are OIDs in the context of this keytool command?

Question

I'm in the process of setting up a 3rd party plugin to Elasticsearch called Search Guard which requires also Search Guard SSL.

While setting up Search Guard SSL, you're required to set up several keystores and SSL certificates. Several scripts are provided by Search Guard SSL, in this directory: example-pki-scripts.

In one of the provided scripts the following command is run:

$ keytool -genkey \
        -alias     $NODE_NAME \
        -keystore  $NODE_NAME-keystore.jks \
        -keyalg    RSA \
        -keysize   2048 \
        -validity  712 \
        -sigalg SHA256withRSA \
        -keypass $KS_PASS \
        -storepass $KS_PASS \
        -dname "CN=$NODE_NAME.example.com, OU=SSL, O=Test, L=Test, C=DE" \
        -ext san=dns:$NODE_NAME.example.com,dns:localhost,ip:127.0.0.1,oid:1.2.3.4.5.5

#oid:1.2.3.4.5.5 denote this a server node certificate for search guard

I've not encountered the use of oid:XXXX before in the -ext switch to keytool.

My questions

• Is the use of a oid: here the recommended way to go here?
• Is it secure to use an oid:XXX here, it seems like security through obscurity?
• Where does the number sequence for oid: come from, is it just arbitrary?

Answer 1

OID stands for an object identifier and in this context it is used to identify an X.509 certificate extension, i.e. additional data fields stored in the certificate, which are not predefined by the standard.

OID is not a secret number, hence it cannot be called a "security through obscurity" mechanism. It is more of an administrative feature.

In this case Search Guard expects (looks for) the value of a san field (subject alternative name). The san is defined in an extension identified by the specified OID of 1.2.3.4.5.5 and it (Search Guard) will (presumably) ignore all data specified in san fields in extensions with any other OIDs.

The value of OID is defined usually by an application and is not standardised, i.e. the developer can choose one arbitrarily as long as it doesn't conflict with other OIDs. Some applications/organisations apply a hierarchical structure to OID.

Refer for example to Red Hat's Standard X.509 v3 Certificate Extension Reference for examples of how specific certificate extensions.