mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
47 lines
3.2 KiB
Plaintext
47 lines
3.2 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * microshift_security_compliance/microshift-custom-ca.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="microshift-custom-cas_{context}"]
|
|
= Using custom certificate authorities for the {microshift-short} API server
|
|
|
|
When {microshift-short} starts, an internal {microshift-short} cluster certificate authority (CA) issues the default API server certificate. By default, clients outside of the cluster cannot verify the {microshift-short}-issued API server certificate. You can grant secure access and encrypt connections between the {microshift-short} API server and external clients. Replace the default certificate with a custom server certificate issued externally by a CA that clients trust.
|
|
|
|
The following steps illustrate the workflow for customizing the API server certificate configuration in {microshift-short}:
|
|
|
|
. Copy the certificates and keys to the preferred directory in the host operating system. Ensure that the files are accessible only with root access.
|
|
|
|
. Update the {microshift-short} configuration for each custom CA by specifying the certificate names and new fully qualified domain name (FQDN) in the {microshift-short} `/etc/microshift/config.yaml` configuration file.
|
|
+
|
|
Each certificate configuration can contain the following values:
|
|
|
|
* The certificate file location is a required value.
|
|
* A single common name containing the API server DNS and IP address or IP address range.
|
|
+
|
|
--
|
|
[TIP]
|
|
====
|
|
In most cases, {microshift-short} generates a new `kubeconfig` file for your custom CA that includes the IP address or range that you specify. The exception is when you specify wildcards for the IP address. In this case, {microshift-short} generates a `kubeconfig` file with the public IP address of the server. To use wildcards, you must update the `kubeconfig` file with your specific details.
|
|
====
|
|
--
|
|
* Multiple Subject Alternative Names (SANs) containing the API server DNS and IP addresses or a wildcard certificate.
|
|
* You can list additional DNS names for each certificate.
|
|
|
|
. After the {microshift-short} service restarts, you must copy the generated `kubeconfig` files to the client.
|
|
|
|
. Configure additional CAs on the client system. For example, you can update CA bundles in the {op-system-base-full} truststore.
|
|
+
|
|
[IMPORTANT]
|
|
====
|
|
Custom server certificates must be validated against CA data configured in the trust root of the host operating system. For more information, read the following documentation:
|
|
|
|
* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/securing_networks/using-shared-system-certificates_securing-networks#the-system-wide-trust-store_using-shared-system-certificates[The system-wide truststore]
|
|
====
|
|
|
|
. The certificates and keys are read from the specified file location on the host. You can test and validate configuration from the client.
|
|
|
|
* If any validation fails, {microshift-short} skips the custom configuration and uses the default certificate to start. The priority is to continue the service uninterrupted. {microshift-short} logs errors when the service starts. Common errors include expired certificates, missing files, or wrong IP addresses.
|
|
|
|
. External server certificates are not automatically renewed. You must manually rotate your external certificates.
|