--- title: Upload and Retrieve the Root Certificate description: The REST API can be used to upload and retrieve the cluster's root certificate. pubDate: 2026-08-17T09:53:44.266Z antora: editUrl: https://github.com/couchbaselabs/docs-enterprise-analytics/edit/release/2.0/modules/reference/pages/deprecated-security-apis/upload-retrieve-root-cert.adoc xref: xref:2.0@enterprise-analytics:reference:deprecated-security-apis/upload-retrieve-root-cert.adoc[] --- [Consult the llms.txt file for a full list of contents](/llms.txt) [View original HTML](/enterprise-analytics/2.0/reference/deprecated-security-apis/upload-retrieve-root-cert.html) # Upload and Retrieve the Root Certificate > The REST API can be used to upload and retrieve the cluster's root certificate. It can also be used to retrieve information about the cluster, by referencing a copy of the root certificate. These methods are deprecated in Enterprise Analytics. ## [](#http-method-and-uri)Http Methods and URIs > [!WARNING] > The APIs listed below for uploading and retrieving the cluster's root certificate are deprecated. Users of Enterprise Analytics should use instead the APIs described in [Certificate Management API](../rest-certificate-management.md). POST /controller/uploadClusterCA POST /settings/security/allowNonLocalCACertUpload GET /settings/security/allowNonLocalCACertUpload GET /pools/default/certificate ## [](#description)Description The `POST` method and `/controller/uploadClusterCA` URI (which are deprecated in 7.1) upload an appropriately configured certificate to the cluster, so that it becomes the root certificate for the cluster. Either the Full Admin or the Security Admin role is required. The certificate must be specified as binary data, in a location on the filesystem, for successful upload to occur. For security reasons, in versions 7.1 and after, by default, this method and URI can be used on _localhost_ only (see [Responses](#reference:upload-retrieve-root-cert.adoc#responses), below, for the associated error message). However, this default setting can be changed, by means of the `POST` method and `/settings/security/allowNonLocalCACertUpload` URI, with the `-d false` flag: this also can be used on _localhost_ only. The status of the current setting can be retrieved with the `GET` method and `/settings/security/allowNonLocalCACertUpload` URI. See [Configure On-the-Wire Security](#reference:rest-setting-security.adoc), for more information. The `GET` method and `/pools/default/certificate` URI are deprecated in 7.1\. After the cluster has been upgraded to 7.1, they continue to return the most recent certificate uploaded by means of the deprecated API `POST /controller/uploadClusterCA`, until at least one new root certificate is uploaded using the new, 7.1 API `POST /node/controller/loadTrustedCAs` (as described in [Load Root Certificates](../load-trusted-cas.md)): following which they always return `400 Bad Request`, with the message `this API is disabled, please use GET /pools/default/trustedCAs` — see [Get Root Certificates](../get-trusted-cas.md), for details. This call is authorized for all Enterprise Analytics roles. ## [](#curl-syntax)Curl Syntax The curl syntax for each call is as follows: curl -X POST --data-binary "@./ca.pem" http://:8091/controller/uploadClusterCA -u : curl -X POST http://:8091/settings/security/allowNonLocalCACertUpload -d -u : curl -X GET http://:8091/settings/security/allowNonLocalCACertUpload -u : curl -X GET http://:8091/pools/default/certificate -u : The certificate specified for upload to the deprecated `POST` method must be an appropriately configured binary, accessible by means of the given path. The certificate must be named `ca.pem`. The certificate-copy returned by the deprecated `GET` method and `/pools/default/certificate` URI should be appropriately saved: for example, with `> `, on the local filesystem. Note that if the URI is extended to `/pools/default/certificate?extended=true`, an _object_ is returned, rather than the raw, pem-encoded certificate-content alone. This object contains the following fields: * `type`: Whether the certificate was generated by Enterprise Analytics, or was uploaded by an administrator. * `pem`: The pem-encoded certificate-content. * `subject`: the Subject Common Name of the certificate. * `expires`: Expiration data. * `warnings`: Warnings, if appropriate. ## [](#responses)Responses For the `POST` method, success gives `200 OK`, and returns the readable text of the uploaded certificate. Additionally, warnings may be displayed — for example, if the root certificate is uploaded (as may be expected) _prior_ to the uploading of corresponding node certificates (whereby the current node certificates have not been signed by the new root), the warning may be as follows: `[{"node":"ns_1@127.0.0.1","message":"Certificate is not signed with cluster CA."}]`. Failure to authenticate gives `401 Unauthorized`. An incorrectly specified URI fails with `404 Object Not Found`. Failure to specify an appropriately configured certificate fails with `400 Bad Request` and the notification `{"error":"Malformed certificate"}` (the message `Couldn’t read data from file` may also be displayed). An incorrectly specified IP address or domain name causes the attempted connection to time out, with a `Failed to connect` notification. If `GET /pools/default/certificates`, which is deprecated in version 7.1, is used on a cluster with more than one root CA, `400 Bad Request` is returned, with the following error message: `deprecated, please use /pools/default/trustedCAs`. If the `POST` method and `/controller/uploadClusterCA` URI (which are deprecated in 7.1) is used from a host other than _localhost_, `400 Bad Request` is returned, with the following error message: `API is accessible from localhost only (this behavior can be changed by means of POST /settings/security/allowNonLocalCACertUpload, see documentation for details)`. For the `GET` method and `/pools/default/certificate` URI, success gives `200 OK`, and returns the readable text of the uploaded certificate. Failure to authenticate gives `401 Unauthorized`. A malformed URI fails, with `404 Object Not Found`. An incorrectly specified IP address or domain name causes the attempted connection to time out, with a `Failed to connect` notification. ## [](#examples)Examples The following example uploads an appropriately configured root certificate: curl -v -X POST http://localhost:8091/controller/uploadClusterCA \ --data-binary "@./ca.pem" \ -u Administrator:password If successful, the call returns `200 OK`, and displays the following output: {"cert":{"type":"uploaded","pem":"-----BEGIN CERTIFICATE-----\nMIIDCzCCAfOgAwIBAgIJ . . . AH\n-----END CERTIFICATE-----\n","subject":"CN=Couchbase Root CA","expires":"2030-08 22T03:14:49.000Z"},"warnings":[{"node":"ns_1@127.0.0.1","message":"Certificate is not signed with cluster CA."}]} The output thus displays in readable form the body of the new root certificate (shown here in truncated form). It also provides, in this case, a warning: indicating that the node certificate for the node is not yet one signed by the new root certificate. This can be remedied by uploadoing an appropriately signed, new node certificate. The following example retrieves the current root certificate: curl -v -X GET http://10.143.201.101:8091/pools/default/certificate \ -u Administrator:password > cert-copy If successful, this returns `200 OK`, with a copy of the current root certificate. This can be inspected at the command line, with a tool such as `more`. Note that success only occurs if the cluster has at most one root CA: if the cluster has more than one root CA, `400 Bad Request` is returned, with the following error message: `deprecated, please use /pools/default/trustedCAs`. ## [](#see-also)See Also An overview of certificate management is provided in [Certificates](#learn:security/certificates.adoc). Steps for certificate creation are provided in [Configure Server Certificates](../../manage/manage-security/configure-server-certificates.md) and [Configure Client Certificates](../../manage/manage-security/configure-client-certificates.md).