Security Opensearch

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
OpenSearch-2.6.0
Dashboard-2.6.0

An expert assessment is needed from the point of view of the security of this solution:

  1. The use of REST API certificates by the command in the standard plugin code is implemented by reinitializing the methods public void initHttpSSLConfig() and public void initTransportSSLConfig()

during the execution of which the following is performed:

  • verification of the server certificate with the root certificate downloaded at the start of Opensearch;

  • checking two lists of IssuerDN, SubjectDN, san for the old and new certificates, respectively, if the server certificate includes an intermediate one,

the lists are not equivalent and the method returns False, and, as a result, an exception when applying new certificates, in our case this is an important factor, since binding to one intermediate CA negatively affects fault tolerance and entails high costs for implementing integration with the automatic certificate issuance agent;

  • if both checks return True, the certificates are applied and placed in the X509Certificate currentX509Certs array.

  • checking the IssuerDN, SubjectDN, san lists for the root certificate is not implemented in the standard source code when applying certificates.

  1. We have made the following changes:
  • added variables that store information about the root certificate downloaded at the start of Opensearch;

  • verification of certificates used by REST API commands with the root certificate is performed for all certificates, the method remains unchanged;

  • verification of private boolean hasValidDNs, which performs checks of compliance of the DN lists of old and new certificates, is performed only for certificates of the root certification authority (ca.crt),

implemented by the condition if (IssuerDN != null&& SubjectDN != null && IssuerDN.equals(SubjectDN)) (valid for the architecture of the Bank);

  1. Initial data for the tests:

3.1 certificates have the following composition:

-ca.crt - contains only the certificate of the root certification authority;

-node.crt - contains a chain of certificates from the server certificate of the node + the certificate of the intermediate certification authority;

-node.pem - contains the root key of the node;

-admin.crt - contains a chain of certificates from the admin certificate + the certificate of the intermediate certification authority;

-admin.pem - contains the admin’s private key;

-truststore.p12 - contains only the certificate of the root certification authority;

-admin-keystore.p12 - contains the admin certificate and the private key + the certificate of the root authentication center;

-keystore.p12 - contains node.crt, node.pem, ca.crt;

3.2 Tested scenarios:

  • the node certificate is replaced on the disk, the certificate is issued to the same intermediate control centers, the certificates are applied (successfully);

  • the node certificate is replaced on the disk, the certificate is issued by another intermediate CC (the entire chain in node.crt and node.pem is replaced), certificates are applied (successfully);

  • the node certificate (the entire chain) and the root certificate (ca.crt) are replaced on the disk, an attempt to apply certificates causes an exception (successfully).

Similarly, the verification of certificates when replacing with a hot one is implemented in Clickhouse, where all three scenarios described above are also valid.

File analysis after compilation showed that the changes affected only the opensearch-security-2.6.0.0-SNAPSHOT file.jar located along the way
opensearch/plugins/opensearch-security/opensearch-security-2.6.0.0-SNAPSHOT.jar.

Hi @Ruslan,

As per documentation (see below) using certificates and private keys in PEM format, or keystore and trust store files in JKS or PKCS12/PFX format" is perfectly fine.

Would you mind sharing the documentation you have followed for your set-up?

Is there a specific question(s) you would like to discuss further?

Best,
mj