From 4a1c8477c98d4a0afd185a674c28e0d31e8f5d2b Mon Sep 17 00:00:00 2001 From: himeshsiriwardana Date: Wed, 6 Nov 2024 14:39:40 +0530 Subject: [PATCH 1/2] removed encrypt docs from guides and fixed a bug --- .../security/asymmetric-encryption/index.md | 2 +- .../encryption/asymmetric-encryption.md | 31 -- .../blue-green-data-encryption-keyrotation.md | 250 --------------- .../guides/encryption/configure-keystores.md | 293 ------------------ .../guides/encryption/create-new-keystores.md | 61 ---- en/includes/guides/encryption/index.md | 190 ------------ ...ge-ca-signed-certificates-in-a-keystore.md | 198 ------------ 7 files changed, 1 insertion(+), 1024 deletions(-) delete mode 100644 en/includes/guides/encryption/asymmetric-encryption.md delete mode 100644 en/includes/guides/encryption/blue-green-data-encryption-keyrotation.md delete mode 100644 en/includes/guides/encryption/configure-keystores.md delete mode 100644 en/includes/guides/encryption/create-new-keystores.md delete mode 100644 en/includes/guides/encryption/index.md delete mode 100644 en/includes/guides/encryption/manage-ca-signed-certificates-in-a-keystore.md diff --git a/en/identity-server/7.0.0/docs/deploy/security/asymmetric-encryption/index.md b/en/identity-server/7.0.0/docs/deploy/security/asymmetric-encryption/index.md index dcc59b901b..c3515b70da 100644 --- a/en/identity-server/7.0.0/docs/deploy/security/asymmetric-encryption/index.md +++ b/en/identity-server/7.0.0/docs/deploy/security/asymmetric-encryption/index.md @@ -1 +1 @@ -{% include "../../../../../../includes/deploy/security/asymmetric-encryption.md" %} +{% include "../../../../../../includes/deploy/security/asymmetric-encryption/index.md" %} diff --git a/en/includes/guides/encryption/asymmetric-encryption.md b/en/includes/guides/encryption/asymmetric-encryption.md deleted file mode 100644 index 64e395fff5..0000000000 --- a/en/includes/guides/encryption/asymmetric-encryption.md +++ /dev/null @@ -1,31 +0,0 @@ -# Asymmetric Encryption - -Asymmetric encryption uses public and private keys to encrypt and decrypt data. While the **public key** of the key pair is shared with external parties, the **private key** is kept secret. When one of the key pairs is used to encrypt a message, the other key can be used to decrypt it. In a **keystore**, you can store both private and public keys, and in a **truststore** you can store only public keys. - -!!! info - For more information on how to configure the keystores to asymmetric key encryption, see [Keystores]({{base_path}}/deploy/security/keystores). - -In WSO2 Identity Server, asymmetric encryption is used by default for the following purposes: - -- Authenticating the communication over Secure Sockets Layer (SSL)/Transport Layer Security (TLS) protocols. -- Encrypting sensitive data such as plain-text passwords found in both product-level and product feature-level configurations/configuration files using [cipher tool]({{base_path}}/deploy/security/encrypt-passwords-with-cipher-tool). -- Encrypting SOAP messages using WS-Security. - -For other types of encryption, [symmetric encryption]({{base_path}}/deploy/security/symmetric-encryption) is used by default. - - -!!! note - To switch to asymmetric encryption, add the following configurations to the `deployment.toml` file located in the `/repository/conf` directory. - - The `[keystore]` property should be added before the `[keystore.primary]` entry in the `deployment.toml` file. The other two properties can be added to the end of the file. - - ```toml - [keystore] - userstore_password_encryption = "InternalKeyStore" - - [system.parameter] - "org.wso2.CipherTransformation"="RSA/ECB/OAEPwithSHA1andMGF1Padding" - - [encryption] - internal_crypto_provider = "org.wso2.carbon.crypto.provider.KeyStoreBasedInternalCryptoProvider" - ``` \ No newline at end of file diff --git a/en/includes/guides/encryption/blue-green-data-encryption-keyrotation.md b/en/includes/guides/encryption/blue-green-data-encryption-keyrotation.md deleted file mode 100644 index 3bbdfe34c3..0000000000 --- a/en/includes/guides/encryption/blue-green-data-encryption-keyrotation.md +++ /dev/null @@ -1,250 +0,0 @@ -# Blue-Green Data Encryption Key Rotation - -This section contains the complete process you need to follow in order to perform symmetric data encryption key rotation in WSO2 Identity Sever(WSO2 IS version 5.11.0 and above). - -Key rotation can be defined as retiring an encryption key and replacing it with a new key. Data is encrypted using a key known as a Data Encryption Key(DEK) and the DEK is then encrypted with another key called Key Encryption Key(KEK). This is known as envelope encryption. Frequent rotations of these encryption keys are considered as an industry best practice by PCI DSS and NIST standards. - -## Why should you rotate encryption keys? - -!!! info - Originator Usage Period (OUP) is the time period during which encryption is applied to data. - -- A cryptoperiod is the time span during which a specific key is authorized for use. [NIST SP 800-57](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf){:target="_blank"} recommends different cryptoperiods for different encryption key types. - - - Symmetric Data Encryption Keys - - - OUP recommended for large volumes of data is about a day or a week. - - OUP recommended for smaller volumes of data is about 2 years. - - - Symmetric Key, Wrapping Keys - - - OUP recommended for a key that wraps a large number of keys is about a day or a week. - - OUP recommended for a key that wraps a smaller number of keys is up to 2 years. - -- Security compliance requirements -- Security breach requirements - -!!! note - The above-mentioned cryptoperiods can vary based on other factors like the sensitivity of data and the amount of data we have. - -## Background - -WSO2 Identity Server has the following key usages for signing/encrypting data and each of these types will have different key rotation requirements. - -- TLS Connection -- Signing and encryption of data (JWT assertions, payloads) shared with external parties (SP, IdP). -- Encryption of sensitive runtime level configuration secrets/user data persisted in datastores and user stores. -- Encryption of sensitive deployment-level configuration data in configuration files. - -From WSO2 IS 5.11.0 onwards, symmetric encryption is used to encrypt the internal sensitive runtime data above. The DEK used to encrypt these data is configured in the `deployment.toml` file and it is protected by a KEK. The secure vault is utilized as of now to protect this DEK. Here, only the rotation of the Data Encryption Key configured in the `deployment.toml` file is considered. - -## DEK rotation frequency - -In the case of a security compliance requirement, we can see that symmetric DEK rotation can be done in 2 years or less based on the volume of data present. - -In a security breach scenario, we must rotate the DEK immediately and re-encrypt all the data to the new DEK. - -## Key Rotation Approach - -WSO2 IS has introduced an external tool that re-encrypts internal data after rotation of the configured symmetric data encryption key. Here, the re-encryption of the identity and registry databases and some configuration files is considered. Apart from that, the tool syncs end-user data that gets generated in the live system to the new setup. - -The external Java client that performs the above tasks can be created by following the steps [here](#how-to-create-the-key-rotation-tool). - -## Tables that support re-encryption - -At the moment, the tables given below are supported for re-encryption. - -| **Table** | **Fields** | -|-----------|---------------| -| IDN_IDENTITY_USER_DATA | TOTP secretKey and verifiedSecretKey claims | -| IDN_OAUTH2_AUTHORIZATION_CODE | OAuth2 authorization codes | -| IDN_OAUTH2_ACCESS_TOKEN | OAuth2 access and refresh tokens | -| IDN_OAUTH_CONSUMER_APPS | Consumer secrets -| WF_BPS_PROFILE | BPS profile password | -| WF_REQUEST | WF request credentials | -| REG_PROPERTY | Keystore passwords, Keystore privatekeyPass, and Entitlement subscriberPasswords | - -## Configuration files that support re-encryption - -At the moment, the configuration files given below are supported for re-encryption. - -| **Configuration file** | **Path** | **Property** | -|---------------------------|-----------|--------------| -| Event publishers | `/repository/deployment/server/eventpublishers` files | Password | -| Super tenant secondary user stores | `/repository/deployment/server/userstores/` files | Password | -| Tenant secondary userstores | `/repository/tenants//userstores/` files | Password | - -## Tables that support syncing - -At the moment, the tables given below can be synced during key rotation from the old setup to the new setup. Any other data will not be persisted in the new setup. - -| **Table** | **Purpose** | **Recommendation** | -|-----------|---------------|-----------------------| -| IDN_IDENTITY_USER_DATA | Identity claims when the identity data store is enabled | Usually recommended to sync if identity management features are enabled in the system | -| IDN_OAUTH2_ACCESS_TOKEN | OAuth 2.0 tokens | Need to sync if the tokens created during the key rotation period need to be valid after key rotation | -| IDN_OAUTH2_ACCESS_TOKEN_SCOPE | OAuth 2.0 scopes | If the IDN_OAUTH2_ACCESS_TOKEN is synced, this table also needs to be synced | -| IDN_OAUTH2_AUTHORIZATION_CODE | OAuth 2.0 authorization codes | Need to sync if the authorization codes created during the key rotation period need to be valid after key rotation | - -## How To Create The Key Rotation Tool - -!!! note - In this section, `` is the directory where the current Identity Server resides, and `` is the directory where the copy of the current Identity Server resides. `` refers to the location [here](https://github.com/wso2/identity-tools/components/org.wso2.carbon.identity.keyrotation){:target="_blank"} and the `` refers to the location of the external tool. - -1. Clone the repository, [identity-tools](https://github.com/wso2/identity-tools){:target="_blank"}. - -2. Build it using maven by running the command `mvn clean install`. - -3. Go to the `/target` folder and copy the `keyrotation-tool--SNAPSHOT.jar` file and the `/target/lib` folder to ``. Get the `properties.yaml` file, `keyrotation.sh` file, and the `triggers` folder from `/src/main/resources` and copy them to the same `` location. - -## Performing blue-green key rotation - -1. Block all privileged user flows and allow only end-user flows. - - !!! note - For the privileged user flows, block all admin services from the load balancer and the management console as well. For end user flows, the above [tables]({{base_path}}/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation/#tables-that-support-re-encryption) will be synced to the ``, so only these end user data flows should be allowed to generate in ``. - -2. Execute the `old.sql` script in the `` identity database to create temp tables and triggers. The triggers can be found inside the `/triggers` folder. - -3. Create a copy of the ``(This copied directory will be referred to as the `NEW_IS_HOME`) and dump `` identity and registry databases and create the new databases. - -4. Drop the temp tables and triggers in the `` identity database using the `new.sql` script. The triggers can be found inside the `/triggers` folder. - -5. Open the `properties.yaml` file in `` and edit the configurations accordingly. - - - oldSecretKey - The symmetric encryption key used in the ``. - - !!! note - If the key is encrypted using cipher tool, decrypt it back as shown [here](https://shagihan.medium.com/decrypt-encrypted-text-with-the-wso2-cipher-tool-15b67624620a){:target="_blank"}. - - - newSecretKey - The new symmetric encryption key. - - !!! tip - Generate using a tool like openssl using the command, `openssl rand -hex 16`. - - - newISHome - The absolute path of the ``. - - oldIdnDBUrl - `` identity database URL. - - oldIdnUsername - `` identity database username. - - oldIdnPassword - `` identity database password (Encoded in [base64](https://www.base64encode.org/){:target="_blank"}). - - newIdnDBUrl - `` identity database URL. - - newIdnUsername - `` identity database username. - - newIdnPassword - `` identity database password (Encoded in [base64](https://www.base64encode.org/){:target="_blank"}). - - newRegDBUrl - `` registry database URL. - - newRegUsername - `` registry database username. - - newRegPassword - `` registry database password (Encoded in [base64](https://www.base64encode.org/){:target="_blank"}). - - enableDBMigrator - Enable/disable re-encryption for the identity and registry databases. - - !!! note - Keep this always **true** to avoid unnecessary issues. - - - enableConfigMigrator - Enable/disable re-encryption for the configuration files. - - !!! note - Keep this always **true** to avoid unnecessary issues. - - - enableSyncMigrator - Enable/disable syncing mechanism. - - !!! note - You only need to set this to **true**, if you have opted in for blue-green key rotation with zero downtime for the end user flows. - - - chunkSize - Size of the record chunks being retrieved from the database tables for syncing. - - ??? tip "Sample configuration written for the properties.yaml file" - - ``` - oldSecretKey: AFA27B44D43B02A9FEA41D13CEDC2E40 - newSecretKey: 1fc0bc7a3805b42afa5f5af07a595f56 - newISHome: /home/IS/wso2is-5.12.0 - oldIdnDBUrl: jdbc:mysql://localhost:3306/regdb?useSSL=false - oldIdnUsername: root - oldIdnPassword: cm9vdA== - newIdnDBUrl: jdbc:mysql://localhost:3306/regdb1?useSSL=false - newIdnUsername: root - newIdnPassword: cm9vdA== - newRegDBUrl: jdbc:mysql://localhost:3306/regdb1?useSSL=false - newRegUsername: root - newRegPassword: cm9vdA== - enableDBMigrator: true - enableConfigMigrator: true - enableSyncMigrator: true - chunkSize: 2 - ``` - - ??? tip "Sample configurations written for DB type URL" - **H2 DB** - ``` - jdbc:h2:~/Desktop/IS/copy/wso2is-5.11.0-beta5-SNAPSHOT/repository/database/WSO2IDENTITY_DB - ``` - **MySQL** - ``` - jdbc:mysql://localhost:3306/idndb?useSSL=false - ``` - **DB2** - ``` - jdbc:db2://localhost:50000/idndb - ``` - **PostgreSQL** - ``` - jdbc:postgresql://localhost:5432/idndb - ``` - **MSSQL** - ``` - jdbc:sqlserver://localhost:1433;databaseName=idndb - ``` - **Oracle DB** - ``` - jdbc:oracle:thin:@localhost:1521/ORCLCDB.LOCALDOMAIN - ``` - -6. Run the tool using the `./keyrotation.sh keyrotation-tool--SNAPSHOT.jar` command from ``. - -7. Edit the `` `deployment.toml` file having the new configured databases and the new key. - -8. Start `` once the re-encryption for the existing DB and config file is done. - -9. When no new entries are being synced in the logs, route traffic to `` and enable all load balancer API endpoints(privileged and end-user flows). - -!!! note "Important" - Do not stop the tool at once, let it sync any remaining data in the temp tables after routing the traffic. - -## Verifying the key rotation - -- Check the log files to verify if re-encryption happened successfully for the 7 identity and registry database tables. Check the logs given below for the successful/failed re-encryption counts of OAuth2 access and refresh tokens. - - ??? tip "DB log sample" - ``` - Successfully updated OAuth2 access and refresh tokens data records in IDN_OAUTH2_ACCESS_TOKEN: 897 - Failed OAuth2 access and refresh tokens data records in IDN_OAUTH2_ACCESS_TOKEN: 0 - ``` - - !!! note - If the key rotation task is successful, the failed logs count should be `0` for all the tables. - -- Check the log files to verify if re-encryption happened successfully for the 3 configuration files. Check the logs given below for the successful/failed re-encryption counts of event publisher configuration files. - - ??? tip "Config file log sample" - ``` - Updated event publisher configuration files: 8 - Failed event publisher configuration files: 0 - ``` - - !!! note - If the key rotation task is successful, the failed logs count should be `0` for all the configuration files. - -- Check the log files to verify if the transformation of the synced data happened successfully for the 4 tables. Check the logs given below for the successful/failed transformation counts of `IDN_IDENTITY_USER_DATA` table. - - ??? tip "Synced log sample" - ``` - Successfully transformed totp data records in IDN_IDENTITY_USER_DATA_TEMP: 2 - Transformation failed totp data records in IDN_IDENTITY_USER_DATA_TEMP: 0 - ``` - - !!! note - If the synced task is successful, the failed logs count should be `0` for all the synced tables. - -- Check for any errors in the log files and carefully analyze the logs if the error can be ignored and other steps can be proceeded with. Otherwise, check what has caused the error. - -## Recovering from any failure - -If the key rotation task stops midway, follow the blue green key rotation user guide steps again. - -If there are errors logged in the log files, carefully go through the errors and find what has caused the error. diff --git a/en/includes/guides/encryption/configure-keystores.md b/en/includes/guides/encryption/configure-keystores.md deleted file mode 100644 index fcbf3f019c..0000000000 --- a/en/includes/guides/encryption/configure-keystores.md +++ /dev/null @@ -1,293 +0,0 @@ -# Configure Keystores - -!!! info "Before you begin" - - 1. Make sure to go through the [recommendations for setting up keystores]({{base_path}}/deploy/security/asymmetric-encryption/use-asymmetric-encryption#recommendations-for-setting-up-keystores) to understand the various keystores you will need. - - 2. If you have not already created the keystores required for your system, see [creating new keystores]({{base_path}}/deploy/security/asymmetric-encryption/create-new-keystores). - - -## Configure default keystore and truststore - -WSO2 Identity Server provides default keystore and truststore files: - -{% if is_version == "7.0.0" %} - -- `wso2carbon.jks`: The default keystore that includes a private key and a self-signed certificate. -- `client-truststore.jks`: The default truststore containing Certificate Authority (CA) certificates and the self-signed certificate from wso2carbon.jks. - -{% else %} - -- `wso2carbon.p12`: The default keystore that includes a private key and a self-signed certificate. -- `client-truststore.p12`: The default truststore containing Certificate Authority (CA) certificates and the self-signed certificate from wso2carbon.jks. - -{% endif %} - -These files are originally located in the `/repository/resources/security` folder. The file settings can be configured by specifying them in the `deployment.toml` file found in the `/repository/conf` folder as follows. - -=== "JKS" - - For the primary keystore: - ``` toml - [keystore.primary] - file_name = ".jks" - password = "" - key_password = "" - type = "JKS" - alias = "" - ``` - - For the truststore: - ``` toml - [truststore] - file_name = "truststore file name>.jks" - password = "" - type = "JKS" - ``` - -=== "PKCS12" - - For the primary keystore: - ``` toml - [keystore.primary] - file_name = ".p12" - password = "" - key_password = "" - type = "PKCS12" - alias = "" - ``` - - For the truststore: - ``` toml - [truststore] - file_name = ".p12" - password = "" - type = "PKCS12" - ``` - - To generate keystores for newly created tenants in PKCS12 format: - ``` toml - [keystore.tenant] - type = "PKCS12" - ``` - -## Use multiple keystores - -Currently, the primary keystore handles both internal data encryption and external message signing. However, it's often necessary to have dedicated keystores for these tasks for the following reasons: - -- External communication, such as SAML and OIDC ID token signing, require keystore certificates to be frequently renewed. - -- Internal data encryption does not require frequent certificate changes as that can render encrypted data unusable. - -In production environments, it is recommended to use distinct keystores for each task with separate trust chains as mentioned below: - -- **Internal Keystore**: Used for encrypting and decrypting internal data (if [asymmetric encryption]({{base_path}}/deploy/security/asymmetric-encryption) is enabled) and for encrypting plaintext passwords in configuration files using the [cipher tool]({{base_path}}/deploy/security/encrypt-passwords-with-cipher-tool). - -- **TLS Keystore**: Used for SSL connections to secure network communication via HTTPS. This keystore typically contains certificates required for establishing SSL/TLS connections. - -- **Primary Keystore**: Used for signing messages and other tasks, serving as the fallback keystore for both internal and external use cases unless specific keystores (like internal or SAML signing keystores) are defined. - -!!! note - All keystores should be placed in `/repository/resources/security`. - -### Configure the internal keystore - -!!! warning - Adding a new keystore for internal data encryption for an existing deployment will make already encrypted data unusable. In such cases, an appropriate data migration effort is needed. - - -To configure the new internal keystore, add the following configuration block to the `keystore.internal` tag of the `deployment.toml` file found in the `/repository/conf` folder. - -=== "JKS" - - ``` toml - [keystore.internal] - file_name = ".jks" - password = "" - key_password = "" - type = "JKS" - alias = "" - ``` - -=== "PKCS12" - - ``` toml - [keystore.internal] - file_name = ".p12" - password = "" - key_password = "" - type = "PKCS12" - alias = "" - ``` - -### Configure TLS keystore - -The TLS keystore is used to manage SSL/TLS connections to {{product_name}}. Given below is the default configuration used internally, which points to the default keystore in your product. - -If you need to configure a different keystore for SSL, you may change the values accordingly. - -```toml -[transport.https.sslHostConfig.certificate.properties] -certificateKeystoreFile = "${carbon.home}/repository/resources/security/$ref{keystore.tls.file_name}" -certificateKeystorePassword = "$ref{keystore.tls.password}" -certificateKeystoreType = "$ref{keystore.tls.type}" -certificateKeyAlias = "$ref{keystore.tls.alias}" -certificateKeyPassword = "$ref{keystore.tls.key_password}" -``` - -The internally used trust-store configurations given below can be changed to define a custom truststore for SSL validations. - -```toml -[transport.https.sslHostConfig.properties] -truststoreFile="${carbon.home}/repository/resources/security/$ref{truststore.file_name}" -truststorePassword = "$ref{truststore.password}" -truststoreType = "$ref{truststore.type}" -``` - -## Add new keys to an existing keystore - -The following guides explain how you can add new keys to existing keystores. -{% if not is_version == "7.0.0" %} - -### Add an asymmetric key pair to an existing keystore - -{% endif %} - -To add a key, - -1. Navigate to the [default keystore](#configure-default-keystore-and-truststore) or other existing keystore on a terminal. - -2. Execute the following command. - - === "Format" - - ```bash - keytool -genkey -alias -keyalg RSA -keysize 2048 -keystore -dname "CN=<>,OU=<>,O=<>,L=<>,S=<>,C=<>"-storepass -keypass - ``` - - === "Sample keytool command" - - ``` bash - keytool -genkey -alias newkey -keyalg RSA -keysize 2048 -keystore wso2carbon.jks -dname "CN=localhost, OU=IT,O={{base_path}},L=SL,S=WS,C=LK" -storepass wso2carbon -keypass wso2carbon - ``` - - !!! tip - If you are planning to delete the newly added keys in the future, it is recommended to maintain separate keystores for internal and external encryption purposes. - -This newly added key can be used for different purposes. - -!!! abstract "" - **Example** - - Follow the instructions given below to set the newly added key as the primary encrypting and signing key: - - 1. Open the `deployment.toml` file in the `/repository/conf` directory. - - {% if is_version == "7.0.0" %} - - 2. Update the `alias` parameter under the `[keystore.primary]` element with the new keystore `alias`. - - ```toml - [keystore.primary] - alias= "newKey" - ``` - {% else %} - - 2. Update the `alias` parameter under the `[keystore.tls]` element with the new keystore `alias`. - - ```toml - [keystore.tls] - alias= "newKey" - ``` - {% endif %} - -{% if not is_version == "7.0.0" %} - -### Add a symmetric secret to a PKCS12 keystore - -To create a PKCS12 keystore with an AES key or add an existing key to the keystore, use the following command. If the keystore is not available, new PKCS12 keystore will be created. - -=== "Format" - - ``` bash - - keytool -genseckey -alias -keyalg AES -keysize 256 -keystore -storetype PKCS12 -storepass -keypass - - ``` - - -=== "Sample keytool command" - - ``` bash - - keytool -genseckey -alias secretkey -keyalg AES -keysize 256 -keystore keystore.p12 -storetype PKCS12 -storepass password -keypass password - - ``` - -!!! abstract "" - - **Example** - - Follow the instructions given below to set the newly added key for symmetric encryption using cipher tool: - - 1. Open the `deployment.toml` file in the `/repository/conf` directory. - - 2. Update the `alias` parameter under the `[keystore.tls]` element with the new keystore `alias`. - - ```toml - [keystore.internal] - file_name = "keystore.p12" - password = "password" - key_password = "password" - type = "PKCS12" - alias= "secretkey" - ``` -{% endif %} - -## View public keys via JWKS - -To view super tenant public key sets via the JWKS endpoint, visit `https://:/oauth2/jwks`. - -!!! abstract "" - **Example** - ```json - // 20190612140905 - // https://localhost:9443/oauth2/jwks - - { - "keys": [ - { - "kty": "RSA", - "e": "AQAB", - "use": "sig", - "kid": "MGZlMjg1MTEyZjE5ZGEyZTI2MWY4ODNlOGM5ZWQwZDIyNzk4MTJiZg", - "alg": "RS256", - "n": "swfFo3uUhsEE5SSJSUrzE4-U-PuYmQn-d71GOV59VcL1_cZRAPS89GE1_M3fmFP4xzB7X4p5vYW7lYYZvOUeZGC0BwR1YXz7uK9VRqXDQM1t_X8yUxtYf6u6hajD5fR3PzirlMzjW1ckojeGTgKS5G-HdixOs2OX2n_kQ5LVUHwIEJ2lryGkfd2Vfq7IBgAifQqYDLcrKqK3-iwF7-foii0lLFg8E_dRuOD5sa6Ec01WjogsA14fZRHzmNKiocjP_FOzmvfq7uHRYta6erTVHtsdOvJBVDy1ANvR0cxGdydfRnGwDYI05kgA5L27MnlN6NMroffDBtHmlCvvwToylw" - }, - { - "kty": "RSA", - "e": "AQAB", - "use": "sig", - "kid": "NTAxZmMxNDMyZDg3MTU1ZGM0MzEzODJhZWI4NDNlZDU1OGFkNjFiMQ", - "alg": "RS256", - "n": "luZFdW1ynitztkWLC6xKegbRWxky-5P0p4ShYEOkHs30QI2VCuR6Qo4Bz5rTgLBrky03W1GAVrZxuvKRGj9V9-PmjdGtau4CTXu9pLLcqnruaczoSdvBYA3lS9a7zgFU0-s6kMl2EhB-rk7gXluEep7lIOenzfl2f6IoTKa2fVgVd3YKiSGsyL4tztS70vmmX121qm0sTJdKWP4HxXyqK9neolXI9fYyHOYILVNZ69z_73OOVhkh_mvTmWZLM7GM6sApmyLX6OXUp8z0pkY-vT_9-zRxxQs7GurC4_C1nK3rI_0ySUgGEafO1atNjYmlFN-M3tZX6nEcA6g94IavyQ" - }, - { - "kty": "RSA", - "e": "AQAB", - "use": "sig", - "kid": "MGZlMjg1MTEyZjE5ZGEyZTI2MWY4ODNlOGM5ZWQwZDIyNzk4MTJiZg_RS256", - "alg": "RS256", - "n": "swfFo3uUhsEE5SSJSUrzE4-U-PuYmQn-d71GOV59VcL1_cZRAPS89GE1_M3fmFP4xzB7X4p5vYW7lYYZvOUeZGC0BwR1YXz7uK9VRqXDQM1t_X8yUxtYf6u6hajD5fR3PzirlMzjW1ckojeGTgKS5G-HdixOs2OX2n_kQ5LVUHwIEJ2lryGkfd2Vfq7IBgAifQqYDLcrKqK3-iwF7-foii0lLFg8E_dRuOD5sa6Ec01WjogsA14fZRHzmNKiocjP_FOzmvfq7uHRYta6erTVHtsdOvJBVDy1ANvR0cxGdydfRnGwDYI05kgA5L27MnlN6NMroffDBtHmlCvvwToylw" - }, - { - "kty": "RSA", - "e": "AQAB", - "use": "sig", - "kid": "NTAxZmMxNDMyZDg3MTU1ZGM0MzEzODJhZWI4NDNlZDU1OGFkNjFiMQ_RS256", - "alg": "RS256", - "n": "luZFdW1ynitztkWLC6xKegbRWxky-5P0p4ShYEOkHs30QI2VCuR6Qo4Bz5rTgLBrky03W1GAVrZxuvKRGj9V9-PmjdGtau4CTXu9pLLcqnruaczoSdvBYA3lS9a7zgFU0-s6kMl2EhB-rk7gXluEep7lIOenzfl2f6IoTKa2fVgVd3YKiSGsyL4tztS70vmmX121qm0sTJdKWP4HxXyqK9neolXI9fYyHOYILVNZ69z_73OOVhkh_mvTmWZLM7GM6sApmyLX6OXUp8z0pkY-vT_9-zRxxQs7GurC4_C1nK3rI_0ySUgGEafO1atNjYmlFN-M3tZX6nEcA6g94IavyQ" - } - ] - } - ``` diff --git a/en/includes/guides/encryption/create-new-keystores.md b/en/includes/guides/encryption/create-new-keystores.md deleted file mode 100644 index 5d5840f92e..0000000000 --- a/en/includes/guides/encryption/create-new-keystores.md +++ /dev/null @@ -1,61 +0,0 @@ -# Create New Keystores - -There are two ways to create keystores for WSO2 Identity Server. You can either generate a keystore using an already existing public key certificate (CA-signed), or you can create the public key certificate at the time of generating the keystore. - -!!! note - If you are creating a new keystore for [data encryption]({{base_path}}/deploy/security/asymmetric-encryption/use-asymmetric-encryption), make sure to acquire a public key certificate that contains the **Data Encipherment** key usage as explained [here]({{base_path}}/deploy/security/asymmetric-encryption/use-asymmetric-encryption/#recommendations-for-setting-up-keystores). - -## Create a keystore using a new certificate - -!!! note - The pubic key certificate we generate for the keystore is self-signed. For a CA-signed certificate, either [import it into the keystore](#add-ca-signed-certificates-to-keystores) or [create a new keystore with a CA-signed certificate](#create-a-keystore-using-an-existing-certificate). - -1. Navigate to the `/repository/resources/security/` directory in a command prompt. All keystores should be stored here. - -2. To create the keystore that includes the private key, execute the following command. Make sure to use the same password for both the keystore and private key. - - === "JKS" - ``` bash - keytool -genkeypair -alias newcert -keyalg RSA -keysize 2048 -keystore newkeystore.jks -dname "CN=, OU=Home,O=Home,L=SL,S=WS,C=LK" -storepass mypassword -keypass mypassword - ``` - - This command will create a keystore with the following details. - - - **Keystore name**: `newkeystore.jks` - - **Alias of public certificate**: `newcert` - - **Keystore password**: `mypassword` - - **Private key password**: `mypassword` - - - === "PKCS12" - ``` bash - keytool -genkeypair -alias newcert -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore newkeystore.p12 -dname "CN=, OU=Home,O=Home,L=SL,S=WS,C=LK" -storepass mypassword -keypass mypassword - ``` - - This command will create a keystore with the following details. - - - **Keystore name**: `newkeystore.p12` - - **Alias of public certificate**: `newcert` - - **Keystore password**: `mypassword` - - **Private key password**: `mypassword` - - !!! tip - - If you did not specify values for the `-keypass` and the `-storepass`, , you will be prompted to enter the keystore password (`-storepass`). It’s advisable to use a password generator to create a strong password. When prompted for `-keypass`, press Enter to use the same password for both the keystore and the key. - - If you did not specify values for `-dname`, you will be asked to provide those details individually. - -## Create a keystore using an existing certificate - -As SSL/TLS is widely used in many systems, certificates may already exist that can be reused. In such situations, you can use an already existing CA-signed certificate to generate your keystore for SSL by using OpenSSL and Java. - -To export certificates of a trust chain into a PKCS12 keystore , execute the following command. Make sure to use the same password for both the keystore and private key. - -``` bash -openssl pkcs12 -export -in .crt -inkey .key -name "" -certfile -out .p12 -``` - -!!! info - To convert the PKCS12 formatted keystore to a Java keystore, execute the following command. - - ``` shell - keytool -importkeystore -srckeystore .pfx -srcstoretype PKCS12 -destkeystore .jks -deststoretype JKS - ``` diff --git a/en/includes/guides/encryption/index.md b/en/includes/guides/encryption/index.md deleted file mode 100644 index 50072a4a34..0000000000 --- a/en/includes/guides/encryption/index.md +++ /dev/null @@ -1,190 +0,0 @@ -# Symmetric Encryption - -Symmetric encryption uses a single key to encrypt and decrypt information. {{product_name}} uses symmetric encryption by default. - -!!! note - If required, you may switch to [asymmetric key encryption]({{base_path}}/deploy/security/asymmetric-encryption/). - -## Why symmetric key encryption? - -From {{product_name}} version 7.0.0 onwards, symmetric key encryption is used as the default encryption mechanism due to the following reasons: - -- **Ability to easily change key stores** - In earlier versions, internal data was encrypted using asymmetric key encryption. This means that whenever the certificates expire, or when the keystore is changed, all encrypted data should be migrated. With the shift to symmetric encryption, this overhead is now removed. The secret key involved in symmetric key encryption is encrypted using asymmetric key encryption. Therefore, the secret key needs to be re-encrypted only when the keystore changes. - -- **Industry-wide usage** - Symmetric key encryption is used as an accepted industry-wide mechanism for encrypting internal sensitive data. This includes both on-premise and cloud platforms. - -- **Post-Quantum Security** - Quantum computers have the potential to break widely-used asymmetric encryption algorithms such as RSA and ECC by efficiently solving the underlying mathematical problems. Symmetric key encryption, on the other hand, is more resistant to quantum attacks. - -!!! info - For more information on symmetric key encryption properties, see [Configure Symmetric Key Encryption]({{base_path}}/deploy/security/symmetric-encryption/use-symmetric-encryption). - -## How is it used? - -{{product_name}} uses the `AES/GCM/NoPadding` algorithm for symmetric key encryption. GCM is a stream cipher and therefore, enables simultaneous encryption of multiple blocks, resulting in faster data encryption. - -{% if is_version == "7.0.0" %} - -The supported key size is AES-128. - -{% else %} - -The supported key sizes are AES-128, AES-192, and AES-256. - -{% endif %} - -{{product_name}} uses [symmetric key encryption]({{base_path}}/deploy/security/symmetric-encryption) to encrypt the following data. - -- Event publisher passwords. -- Secondary user store properties. -- `secretKey` and `verifiedSecretKey` claims of TOTP authentication. -- OAuth 2.0 authorization codes, access tokens, refresh tokens, and consumer secrets (when encryption is enabled). - - !!! note - - To enable encryption of OAuth 2.0 authorization codes, access tokens, refresh tokens, and consumer secrets, add the following configuration to the `deployment.toml` found in the `/repository/conf/` directory. - - ```toml - [oauth.extensions] - token_persistence_processor = "org.wso2.carbon.identity.oauth.tokenprocessor.EncryptionDecryptionPersistenceProcessor" - ``` - -- Secondary keystore passwords and private-key passwords -- BPS profile passwords -- Workflow request credentials - -For other types of encryption, [asymmetric encryption]({{base_path}}/deploy/security/asymmetric-encryption) is used by default. - -## Generate a secret key - -For enhanced security, it is recommended to generate your own secret key for symmetric key encryption in {{product_name}}. - -!!! warning - All configuration changes should be applied before starting {{product_name}} for the first time. Otherwise, a [key rotation]({{base_path}}/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation) will be required. - -To do so, - -{% if is_version == "7.0.0" %} - -1. Generate a unique 128-bit secret key. If you use OpenSSL, the command will be as follows: - - ```bash - openssl rand -hex 16 - ``` - -2. Add your generated key to the `deployment.toml` found in the `/repository/conf/` directory as follows: - - ```toml - [encryption] - key = "9a131db7d3fce3adb0850b486bfc6528" - ``` - - !!! note - - It is advised to encrypt the symmetric encryption key with a cipher tool as mentioned [here]({{base_path}}/deploy/security/encrypt-passwords-with-cipher-tool). -{% else %} - -1. Generate a unique 256-bit secret key. If you use OpenSSL, the command will be as follows: - - ```bash - openssl rand -hex 32 - ``` - -2. Add your generated key to the `deployment.toml` found in the `/repository/conf/` directory as follows: - - ```toml - [encryption] - key = "d13e3b2ea4c42eb4a23fd110facb72a596ecd84ecd5297a13065f1877393eccf" - ``` - -{% endif %} - -If a custom encryption key is not provided, the value of `encryption.key` in this configuration file will be used as the default key. - -!!! note "Important" - - It is highly recommended to encrypt the secret key using the [cipher tool]({{base_path}}/deploy/security/encrypt-passwords-with-cipher-tool/). - -======= -# Keystores and Truststores - -## Keystores - -A keystore is a secure repository for storing private keys and their associated public key certificates. These elements are used to protect sensitive information and establish secure communication channels. Each keystore entry consists of: - -- **Private Key:** Used for decrypting data encrypted with the corresponding public key. It should be kept confidential. -- **Digital Certificate** Embeds the public key and verifies the identity of the key owner. It includes details such as the owner’s identity and the certificate’s validity. -- **Certificate Chain:** Includes the certificates of the Certificate Authorities (CAs) that signed the public key certificate. This may include root CA certificates or intermediate CA certificates. - -## Truststores - -A truststore is a repository for storing trusted CA certificates. It validates the identity of external parties by checking the CA certificates against those stored in the truststore. The truststore contains: - -- **Trusted CA Certificates:** Certificates from CAs that are trusted for verifying the identity of third-party systems. -- **Trusted Certificates:** Certificates of specific third parties that the system intends to communicate with directly. - -## Keystore formats - -With IS 7.0.0 onwards, you can configure to utilize keystore and truststore in both JKS and PKCS12 formats. - - -### JKS - -JKS is a proprietary format used mainly in Java applications for storing keys and certificates. It is easy to use within Java environments but has limited interoperability with non-Java systems and supports fewer cryptographic algorithms. - -### PKCS12 - -PKCS12 is a standard format supported across various platforms, offering high interoperability and advanced cryptographic support. It can store both private and public keys along with certificates in a single file. - -!!! tip - - To convert an existing JKS keystore to PKCS12, execute the following command: - - === "Format" - - ``` bash - keytool -importkeystore -srckeystore .jks -destkeystore .p12 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass -deststorepass - ``` - - === "Sample keytool command" - - ``` bash - keytool -importkeystore -srckeystore wso2carbon.jks -destkeystore wso2carbon.p12 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass wso2carbon -deststorepass wso2carbon - ``` - - -## Recommendations for setting up keystores - -Follow the recommendations given below when you set up your keystores. - -- Maintain one primary keystore for encrypting sensitive internal data such as admin passwords and any other sensitive information found at both product-level and product feature-level configurations/configuration files. - - !!! note - The primary keystore will also be used for signing messages when the product communicates with external parties (such as SAML, OIDC id_token signing). - - !!! tip - You can have separate keystores for encrypting sensitive information for internal data encryption as a recommended practice. See [Configuring Keystores in WSO2 Identity Server]({{base_path}}/deploy/security/asymmetric-encryption/configure-keystores-in-wso2-products) for details. - -- Maintain another secondary keystore, containing the server’s public key certificate for authenticating communication over SSL/TLS (for both Tomcat and Axis2 level HTTP connections). - -- All instances of WSO2 Identity Server must use the same keystore for SSL. - -- It is recommended to use a CA-signed keystore for SSL communication. However, this is not mandatory. Even a self-signed certificate may suffice if it can be trusted by the clients. - -- The keystore used for SSL must contain the same password for the keystore and private key due to a Tomcat limitation. - -- The primary keystore used for admin passwords and other data encryption requirements can be a self-signed one. There is no value added by using a CA-signed keystore for this purpose as it is not used for any external communication. - -- The primary keystore's public key certificate must have the **Data Encipherment** key usage to allow direct encipherment of raw data using its public key. This key usage is already included in the self-signed certificate that is included in the default `wso2carbon.jks` keystore. If the **Data Encipherment** key usage is not included in your public key certificate, the following error can occur when you attempt data encryption. - - !!! error - ``` java - Exception in thread "main" org.wso2.ciphertool.CipherToolException: Error initializing Cipher at org.wso2.ciphertool.CipherTool.handleException(CipherTool.java:861) at org.wso2.ciphertool.CipherTool.initCipher(CipherTool.java:202) at org.wso2.ciphertool.CipherTool.main(CipherTool.java:80) Caused by: java.security.InvalidKeyException: Wrong key usage at javax.crypto.Cipher.init(DashoA13..) at javax.crypto.Cipher.init(DashoA13..) at org.wso2.ciphertool.CipherTool.initCipher(CipherTool.java:200)... 1 more - ``` - -- Optionally, you can set up separate keystores for message-level data encryption in WS-Security. - -- If you already have the required keystores, you can generate CA-signed certificates and import them into the keystores. It is not recommended to create new keystores for the purpose of replacing the certificates in the keystore. See [Add CA-signed certificates]({{base_path}}/deploy/security/asymmetric-encryption/manage-ca-signed-certificates-in-a-keystore#add-ca-signed-certificates-to-keystores) to keystores for instructions. - -!!! info "Related topics" - - [Deploy: Create New Keystores]({{base_path}}/deploy/security/asymmetric-encryption/create-new-keystores) - - [Deploy: Configure Keystores]({{base_path}}/deploy/security/asymmetric-encryption/configure-keystores-in-wso2-products) diff --git a/en/includes/guides/encryption/manage-ca-signed-certificates-in-a-keystore.md b/en/includes/guides/encryption/manage-ca-signed-certificates-in-a-keystore.md deleted file mode 100644 index 37faa18b1b..0000000000 --- a/en/includes/guides/encryption/manage-ca-signed-certificates-in-a-keystore.md +++ /dev/null @@ -1,198 +0,0 @@ -# Manage CA-Signed certificates in a keystore - -## Add CA-signed certificates to keystores - -!!! note - It is not required to create a new keystore everytime you need to add a CA-signed certificate. - -### Step 1: Generate certificate - -First, you need to generate a certificate signing request (CSR) for your keystore (`.jks` file). This CSR file can then be certified by a certification authority (CA), which is an entity that issues digital certificates. These certificates certify the ownership of a public key. - -1. Execute the following command to generate the CSR: - - ``` bash - keytool -certreq -alias certalias -file newcertreq.csr -keystore newkeystore.jks - ``` - - !!! note - Use the same `alias` that you used during the keystore creation process. - - Now you will be prompted to provide the `keystore password`. Once the password is given, the command will output the `newcertreq.csr` file to the `/repository/resources/security/` directory. This is the CSR that you must submit to a CA. - -2. You must provide this CSR file to the CA. For testing purposes, try the [90 days trial SSL certificate from Comodo](https://www.ssldragon.com/product/comodo-trial-ssl/){:target="_blank"}. - - !!! tip - It is preferable to have a wildcard certificate or multiple domain certificates if you wish to have multiple subdomains for deployment. For such requirements, you must modify the - CSR request by adding subject alternative names. Most of the SSL providers give instructions to generate the CSR in such cases. - -3. After accepting the request, a signed certificate is provided along with a root certificate and several intermediate certificates (depending on the CA) as a bundle (`.zip` file). - - !!! abstract "" - **Sample certificates provided by the CA (Comodo)** - - The Root certificate of the CA: `AddTrustExternalCARoot.crt` - Intermediate certificates: `COMODORSAAddTrustCA.crt` , `COMODORSADomainValidationSecureServerCA.crt` - SSL Certificate signed by CA: `test_sampleapp_org.crt` - -### Step 2: Import certificates to the keystore - -Follow the steps given below to import the CA-signed certificate to your keystore. - -1. To add the root CA certificate and the two (related) intermediate certificates, execute the following commands. - - === "JKS" - ``` bash - keytool -import -v -trustcacerts -alias ExternalCARoot -file AddTrustExternalCARoot.crt -keystore newkeystore.jks -storepass mypassword - keytool -import -v -trustcacerts -alias TrustCA -file COMODORSAAddTrustCA.crt -keystore newkeystore.jks -storepass mypassword - keytool -import -v -trustcacerts -alias SecureServerCA -file COMODORSADomainValidationSecureServerCA.crt -keystore newkeystore.jks -storepass mypassword - ``` - - === "PKCS12" - ``` bash - keytool -import -v -trustcacerts -alias ExternalCARoot -file AddTrustExternalCARoot.crt -keystore newkeystore.p12 -storetype PKCS12 -storepass mypassword - keytool -import -v -trustcacerts -alias TrustCA -file COMODORSAAddTrustCA.crt -keystore newkeystore.p12 -storetype PKCS12 -storepass mypassword - keytool -import -v -trustcacerts -alias SecureServerCA -file COMODORSADomainValidationSecureServerCA.crt -keystore newkeystore.p12 -storetype PKCS12 -storepass mypassword - ``` - -2. To add the CA-signed SSL certificate to the keystore, execute the following command. - - !!! note - Make sure to use the same alias (i.e., `newcert`) that you used while creating the keystore. - - === "JKS" - ``` bash - keytool -import -v -alias newcert -file -keystore newkeystore.jks -keypass mypassword -storepass mypassword - ``` - - === "PKCS12" - ``` bash - keytool -import -v -alias newcert -file -keystore newkeystore.p12 -keypass mypassword -storetype PKCS12 -storepass mypassword - ``` - -Now you have a Java keystore, which includes a CA-signed public key certificate that can be used for SSL in a production environment. Next, you may need to add the same CA-signed public key certificate to the `client-truststore.jks` file. This will provide security and trust for backend communication/inter-system communication of WSO2 Identity Server via SSL. - -### Step 3: Import certificates to the truststore - -In SSL handshake, the client needs to verify the certificate presented by the server. For this purpose, the client usually stores the certificates it trusts, in a truststore. To enable secure and trusted -backend communication, WSO2 Identity Server is shipped with a truststore named `client-truststore.jks`, which resides in the same directory as the default keystore (`/repository/resources/security/`). - -Follow the steps given below to import the same CA-signed public key certificate (which you obtained in the previous step) into your WSO2 Identity Server's default truststore (`client-truststore.jks`). - -1. Get a copy of the `client-truststore.jks` file from the `/repository/resources/security/` directory. -2. To export the public key from your keystore file, execute the following command. - - === "JKS" - ``` bash - keytool -export -alias certalias -keystore newkeystore.jks -file .pem - ``` - - === "PKCS12" - ``` bash - keytool -export -alias certalias -keystore newkeystore.p12 -storetype PKCS12 -file .pem - ``` - -3. Import the public key you extracted in the previous step to the `client-truststore.jks` file using the following command. - - ``` bash - keytool -import -alias certalias -file .pem -keystore client-truststore.jks -storepass wso2carbon - ``` - - Now, you have an SSL certificate stored in a Java keystore and a public key added to the `client-truststore.jks` file. Note that both these files should be in the `/repository/resources/security/` directory. You can now replace the default `wso2carbon.jks` keystore in your WSO2 Identity Server instance with the newly created keystore by updating the relevant configuration files. - -## Renew a CA-Signed Certificate in a Keystore - -A digital certificate has a validity period, after which the certificate expires. Once a certificate expires, it is no longer valid, and it can cause the client-server communication to fail at the SSL handshake level. Therefore, it is important to plan certificate renewal ahead of time. Neglecting certificate renewal can eventually lead to a catastrophic situation such as a major service outage. - -Following are the high-level steps you need to follow to renew an expired certificate in a keystore. - -!!! tip - - Use the same certificate authority that you used when you first got the public certificate. If you use a different certificate authority for certificate renewal, you will have to import the new CA certificate as well as the intermediate certificates to the keystore and the client’s truststore. - - If the certificate authority’s certificate is not in the keystore, you will get the following error when you try to import the CA-signed certificate to the keystore. - - ``` java - keytool error: java.lang.Exception: Failed to establish chain from reply - ``` - - To overcome the above error, make sure to first import the CA-signed certificate as well as the intermediate certificates to the keystore in the correct order. - -Now let's take a look at each high-level step in detail. - -### Step 1: Check the certificate validity period - -Follow one of the steps below to view the validity period of a certificate. - -- **If you have a public hostname**, go to and specify your server hostname. SSL hopper lists all the information about the server certificate. -- **If you have a java keystore**, execute the following keytool command to view the certificate information: - - ``` java - keytool -list -keystore -alias -v - ``` - - This prompts for the keystore password. Once you specify the password, you can view the certificate information in a human-readable format where the validity period is displayed as follows. - - ``` java - Valid from: Sun Jun 18 19:26:25 IST 2017 until: Sat Jun 19 19:26:25 IST 2027 - ``` - -- **If you have the certificate file**, execute the following openssl command. - - ``` java - x509 -in -text -noout - ``` - - This displays the validity as follows: - - ``` java - Validity - Not Before: Jun 18 13:56:25 2017 GMT - Not After : Jun 19 13:56:25 2027 GMT - ``` - -- **If it is a website**, you can view the certificate information via the browser. All major browsers provide the capability to view certificate information. - -Once you view the validity period of a certificate and if it says that the certificate is about to expire or has already expired, you should generate a Certificate Signing Request (CSR) and get a new certificate generated from the CA. - -### Step 2: Generate a CSR - -Depending on the type of keystore you have, follow one of the steps below to generate a Certificate Signing Request (CSR). - -- **If you have a java keystore**, execute the following command. - - ``` java - keytool -certreq -alias -file -keystore - ``` - - !!! tip - If you want to generate a CSR with a subject alternative name (SAN), be sure to use the `-ext` attribute in the keytool command to specify the required SAN. - - Following is a sample keytool command that includes a SAN. - - ``` java - keytool -certreq -alias test -file test.csr -keystore test.jks -ext SAN=dns:test.example.com - ``` - -- **If you have the private key and public key**, execute the following command: - - ``` java - openssl x509 -x509toreq -in -out -signkey - ``` - -Once you generate the CSR, you need to submit the CSR to your certificate authority to get a new CA-signed certificate. - -After you obtain a new certificate, you have to import the new certificate to a keystore if you are using a Java keystore. - -### Step 3: Import the new certificate to the keystore - -To import a new certificate to a keystore, execute the following command: - -``` java -keytool -import -v -trustcacerts -alias -file -keystore -``` - -!!! tip - To view information related to the renewed certificate, execute the following keytool command. - - ``` java - keytool -list -keystore -alias -v - ``` From 18230e300d6e3abb4309f43c0712daefdc181873 Mon Sep 17 00:00:00 2001 From: himeshsiriwardana Date: Wed, 6 Nov 2024 15:07:24 +0530 Subject: [PATCH 2/2] fixed a bug in ca signed certificate doc --- .../keystores/manage-ca-signed-certificates-in-a-keystore.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/identity-server/7.0.0/docs/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md b/en/identity-server/7.0.0/docs/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md index 03c5b76111..1b3e14c893 100644 --- a/en/identity-server/7.0.0/docs/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md +++ b/en/identity-server/7.0.0/docs/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md @@ -1 +1 @@ -{% include "../../../../../../includes/deploy/security/keystores/index.md" %} +{% include "../../../../../../includes/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md" %}