vania-janet/multiturn-rag-retrieval-data huggingface dataset:
But, similar to certificates generated by a Fabric CA, they do expire, and their expiration date needs to be monitored to avoid a network outage caused by their expiry. And like certificates generated by a Fabric CA, expiration dates of certificates from an external CA are visible throughout the console. Before the certificates expire you need to request new certificates from your certificate provider, and then use the console to update them across your network. The process to update them using the console depends on the certificate type.



 Peer and ordering node enrollment and TLS certificates 

If the certificates are for peer or ordering node enrollment or TLS certificates, they can be updated by completing the following steps:



1. Open the peer or ordering node tile and click the Settings icon and then Update certificates:

Zoom

![How to update certificates from an external CA](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/ext-ca-certs-update.png)

Figure 12. How to update certificates from an external CA
2. Click Add certificate and browse to the updated certificate .pem files. You do not have to replace all of them, but if you provide an enrollment certificate, you also need to provide the associated key file. And likewise, if you provide a TLS certificate you also need to provide the associated key.
3. When you click Update certificates, the peer or ordering node is restarted. Verify the renewal is successful by examining the updated enrollment and TLS certificate expiration dates.



If you updated the ordering node TLS certificate, the following additional steps are required:

Update the consenter set on the ordering service system channel (TLS certificate renewal only)

When you update the TLS certificate, you also need to update the consenter set on the ordering service system channel. This action ensures that any new application channels which include this ordering node as a consenter will use the updated TLS certificate.

In order to update the ordering service, you must have the ordering service organization admin identity in your wallet.



1.
Click Commit to move the master key to the Full committed state.
2. If prompted, in smart card reader 1, insert an EP11 smart card with an administrator signature key that is defined to the selected crypto units and enter the smart card PIN on the smart card reader PIN pad. Repeat this operation if prompted for more EP11 smart cards with signature keys.



After the process is complete, the new master key register is in Full committed state.
3. If you have any encryption keys that are encrypted with the current master key by using the GREP11 API and are stored locally, call the [RewrapKeyBlob GREP11 API](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-grep11-api-refgrep11-rewrapKeyBlob) to reencrypt the keys with the new master key.

Make sure to perform this step before you rotate the master key. Otherwise, your keys that are encrypted with the current master key cannot be reencrypted and used.
4. To reencrypt keys in the key management service keystore using the master key in the new master key register, click the Rotate button and click Yes on the message window. It might take approximately 60 seconds to reencrypt 3000 keys.

When you receive the following messages for system operations, click OK to continue:



1. Master key rotation started.
2. MKS CRK rewrap successful, waiting on cryptounit-mk-setimm.
3. Master key rotation successful.



The new master key is now in Valid state in the current master key register. Check out [Master key rotation](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-master-key-rotation-intro) for information on how the key states change.



You have successfully rotated the current master key with the new master key. Your encryption keys are now well protected by the new master key.
Why does the Ingress status show an ESSWS error? 

Virtual Private Cloud

Classic infrastructure

Satellite

  What’s happening 

When you check the status of your cluster's Ingress components by running the ibmcloud ks ingress status-report get command, you see an error similar to the following example.

The secret status shows a warning (ESSWS).

  Why it’s happening 

There was an error when attempting to apply the secret to your cluster.

To view the specific error, run the ibmcloud ks ingress secret ls commands and review the Status column.

Error api_request_failed
:   There was an issue uploading the new certificate to the registered instance for the cluster. Verify the instance details using the ibmcloud ks ingress instance ls command.

Error secret_apply_failed
:   There was an issue applying the secret to your cluster. Follow the steps to [ensure your cluster control plane is healthy](https://cloud.ibm.com/docs/containers?topic=containers-debug_masterreview-master-health).

Error namespace_not_found
:   The namespace for the secret is no longer found in the cluster. If you no longer need the secret for that namespace, you can remove it with the ibmcloud ks ingress secret rm command. Otherwise, recreate the namespace on the cluster.

If the issue persists, contact support. Open a [support case](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar). In the case details, be sure to include any relevant log files, error messages, or command outputs.
Repeat substep 4 and 5 for each master key part to be loaded.
7. If prompted, in smart card reader 1, insert the EP11 smart card with an administrator signature key that is defined to the selected crypto units, and enter the smart card PIN on the smart card reader PIN pad.



After all master key parts are loaded, the new master key register is in Full uncommitted state.





 Commit the new master key register 



1. Click Commit to move the master key to the Full committed state.
2. If prompted, in smart card reader 1, insert an EP11 smart card with an administrator signature key that is defined to the selected crypto units and enter the smart card PIN on the smart card reader PIN pad. Repeat this operation if prompted for more EP11 smart cards with signature keys.



After the process is complete, the new master key register is in Full committed state.





 Activate the master key 

Perform this step only when you are setting up a service instance for the first time and the key storage is empty. This command changes the value in the current master key register. If this command is run when key storage contains keys, and those keys are encrypted by using a master key value that is different from the value that is placed in the current master key register by this command, the keys in key storage become unusable.



1. Click Set immediate to move the value of the new master key register to the current master key register and clear the new master key register.
2. Click Yes if you are ready to move the master key to the current master key register. This action can't be reversed.
3. If prompted, insert an EP11 smart card with an administrator signature key that is defined to the selected crypto units in smart card reader 1. And then, enter the smart card PIN on the smart card reader PIN pad.



The crypto units in the current master key register is now in Valid status, which indicates that your master key is loaded to your service instance.

If you want to clear your current master key in a later phase, click Clear current.









 What's next
You need the certificate authority smart card that is used to initialize the EP11 smart card to unblock an EP11 smart card. To unblock an EP11 smart card, select EP11 Smart Card > Unblock EP11 smart card from the menu, and follow the prompts.

A certificate authority smart card becomes blocked if an incorrect PIN is entered five times. If a certificate authority smart card becomes blocked, it can't be unblocked.





 Smart card readers 

A smart card reader is a device that attaches to a workstation and allows the workstation to communicate with a smart card. To access a smart card, the smart card must be inserted in the smart card reader. Most smart card operations require the smart card PIN to be entered on the smart card reader PIN pad.

A driver for the smart card reader must be installed on the workstation before the smart card reader can be used. For more information, see [Installing the smart card reader driver](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-prepare-management-utilitiesinstall-smart-card-reader-driver).





 Smart Card Utility Program 

The Smart Card Utility Program is one of the two applications that are installed as part of the Management Utilities. It sets up and manages the smart cards that are used by the Trusted Key Entry (TKE) application.





 Trusted Key Entry application 

The Trusted Key Entry (TKE) application is one of the two applications that are installed as part of the Management Utilities. It uses smart cards to load master keys in service instances and to perform other configuration tasks for service instances.





 Keep Your Own Key 

Hyper Protect Crypto Services supports the Keep Your Own Key (KYOK) feature. You can configure the master key to take the full control of the cloud HSM, so that you have full control and authority over encryption keys that you can bring, control, and manage. No one except you have access to your encryption keys.





 PKCS 11 

Public-Key Cryptography Standards (PKCS) #11 API defines a platform-independent API to cryptographic tokens, such as HSM and smart cards.
Compare the outputs of the two previous commands and identify the subdomains that have incorrect addresses registered.
4. If you no longer need a specific domain, you can use the ibmcloud oc ingress domain rm[command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-cliingress-domain-rm) to remove it.
5. If you still need the domain, you can update the registered addresses for the domain by using the ibmcloud oc ingress domain update[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliingress-domain-update) command.

Note that you must include all addresses you want to be registered as the update operation replaces the currently registered addresses. For example, if 52.137.182.166 is currently registered to your domain and you want to add 52.137.182.270, you must specify --ip 52.137.182.166 --ip 52.137.182.270 in the command.
6. Wait a 15-30 minutes, then check if the warning is resolved.
7. If the issue persists, contact support. Open a [support case](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar). In the case details, be sure to include any relevant log files, error messages, or command outputs.
1 year Wallet tab: Click the peer organization admin identity tile to view the expiration date of the certificate and private key. <br> <br>Peer node: If Node OU support is not enabled for the peer MSP, open peer tile and view the Admin Cert Expiration in the left column. <br> <br>MSP tab: Open peer organization MSP tile, the admin certificate expiration date is listed in left column. <br> <br>Channel details tab: Open channel and click member tile to view expiration date. [Enroll new identity](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-manual-enroll) No action is required when Node OU is enabled for the MSP. <br> <br>Otherwise, [Append the admin certificate to the MSP definition](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-manual-update-msp). No action is required when Node OU is enabled for the MSP. <br> <br>Otherwise, [Associate new admin identity on peer](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-manual-update-node-identity). No action is required when Node OU is enabled for the MSP. <br> <br>Otherwise, [Update channel](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-manual-update-channel-peer) <br> <br>or <br> <br>[Bulk admin certificate update with Ansible playbooks](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-bulk-ansible) All consortium members and ordering service admin need to import the updated MSP into their Organizations tab.
Review the origin web server’s TLS certificates and verify that:



1. The certificate is not expired
2. The certificate is not revoked
3. The certificate is signed by a Certificate Authority (not self-signed)
4. The requested or target domain name and hostname are in the certificate's Common Name or Subject Alternative Name
5. Your origin web server accepts connections over port 443
6. Temporarily pause CIS and go to https://www.sslshopper.com/ssl-checker.htmlhostname=www.example.com (replace www.example.com with your hostname and domain) to verify no issues exists with the origin TLS certificate









 Error 530 

Error 530 is accompanied by an error code in the 1XXX range. See [Troubleshooting 1XXX errors](https://cloud.ibm.com/docs/cis?topic=cis-html-1xxx-errors) for more information.
The certificate for TLS secret expired or will expire soon (ESSEC). For more information, see [Why does the Ingress status show an ESSEC error?](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-ingress-essec). 
 The Opaque secret field expired or will expire soon (ESSEF). For more information, see [Why does the Ingress status show an ESSEF error?](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-ingress-essef). 
 The secret status shows a warning (ESSWS). For more information, see [Why does the Ingress status show an ESSWS error?](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-ingress-essws). 
 The secret is not present on the cluster or is in the wrong namespace (ESSDNE). For more information, see [Why does the Ingress status show an ESSDNE error?](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-ingress-essdne). 
 The external provider for the given subdomain has authorization issues (ERRDSAISS). For more information, see [Why does the Ingress status show an ERRDSAISS error?](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-ingress-errdsaiss) 
 The subdomain has TLS secret issues (ERRDSISS). For more information, see [Why does the Ingress status show an ERRDSISS error?](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-ingress-errdsiss). 
 The subdomain has DNS resolution issues (ERRDRISS). For more information, see [Why does the Ingress status show an ERRDRISS error?]
Why do I see SyncLoadBalancerFailed errors when creating a VPC cluster? 

 What’s happening 

When setting up load balancing on my VPC cluster, I see an error message similar to the following.

Warning CreatingCloudLoadBalancerFailed 55s ibm-cloud-provider Error on cloud load balancer kube-<CLUSTERID>-<SERVICE_UUID> for service <NAMESPACE>/<SERVICE_NAME> with UID <SERVICE_UUID>: Failed ensuring LoadBalancer: FindLoadBalancer failed: FindLoadBalancer failed: An error occurred while performing the 'authenticate' step: 400 Bad Request [{"incidentID":"XXX","code":"XXX","description":"Error message from IAM: '401 Unauthorized. Transaction-Id: XXX Details: {"errorCode":"BXNIM0430E","errorMessage":"User login from given IP address is not permitted.","errorDetails":"The user has configured IP address restriction for login. The given IP address 'XXXX' is not contained in the list of allowed IP addresses.","context":...,"type":"Authentication"}]
Warning SyncLoadBalancerFailed 55s service-controller Error syncing load balancer: failed to ensure load balancer: Error on cloud load balancer kube-<CLUSTERID>-<SERVICE_UUID> for service <NAMESPACE>/<SERVICE_NAME> with UID <SERVICE_UUID>:: Failed ensuring LoadBalancer: FindLoadBalancer failed: FindLoadBalancer failed: An error occurred while performing the 'authenticate' step: 400 Bad Request [{"incidentID":"XXX","code":"XXX","description":"Error message from IAM: '401 Unauthorized. Transaction-Id: XXX Details: {"errorCode":"BXNIM0430E","errorMessage":"User login from given IP address is not permitted.","errorDetails":"The user has configured IP address restriction for login.
* [MSP Admin certificate](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-manual-renewal-admin)
* [Certificates from an external CA](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-manual-ext-ca)







 Renew the CA TLS certificate 

Because automatic renewal of peer and ordering node enrollment certificates is not possible when the CA TLS certificate expires, it is important to keep your CA TLS certificate current. Transactions on the network can continue to be successfully processed even if the CA TLS certificate expires, but you are not able to enroll new identities, which is required when certificates expire.

The process to renew the CA TLS certificate is same regardless of whether it has expired or not, although it is not available on an imported CA. In that case, the update needs to be performed from the console where the CA was deployed.



1. Open the CA tile and click the Settings icon.
2. Click Renew TLS certificate. The certificate is replaced and the CA is restarted.
3. After the CA is restarted, click the Refresh certificates icon next to the CA Settings icon to update the console.
4. For your network to work, it is required that you update all of the associated nodes that are currently using the original TLS certificate with the new TLS certificate to secure their communications. Click the Settings icon again and this time click Update associated nodes. All of the nodes in the list of associated nodes need to be updated.



This update requires a brief restart of the associated nodes. For zero downtime and to ensure nodes are still available to process transactions, it is recommended that the updates are performed on one node at a time.

Because the console only shows CA TLS certificate expiration dates if they are within five years, it is possible that the expiration date of the CA TLS certificate is not visible when you open the CA tile. If you've just successfully renewed the certificate, the expiration date is no longer visible on the page.





 Renew Peer enrollment and TLS Certificates
Why does the Ingress status show an ERRDSAISS error? 

Virtual Private Cloud

Classic infrastructure

Satellite

You can use the ibmcloud oc ingress status-report ignored-errors add command to add an error to the ignored-errors list. Ignored errors still appear in the output of the ibmcloud oc ingress status-report get command, but are ignored when calculating the overall Ingress status.

  What’s happening 

When you check the status of your cluster's Ingress components by running the ibmcloud oc ingress status-report get command, you see an error similar to the following example.

The external provider for the given subdomain has authorization issues (ERRDSAISS).

  Why it’s happening 

The Kubernetes Service is unable to access the external domain provider used for the given subdomain.

  How to fix it 

Complete the following steps based on your external domain provider.



*  For external Akamai or Cloudflare domains, make sure that you create a valid credential for the cluster by using ibmcloud ks ingress domain credential set command.
*  For domains provisioned with Cloud Internet Services, ensure that the service-to-service authorization is in place. For more information, see [Setting up domains with IBM Cloud Internet Services](https://cloud.ibm.com/docs/containers?topic=containers-ingress-domainsingress-domain-cis). If you no longer want to use the domain you registered, then you can remove it by using the ibmcloud ks ingress domain rm --c CLUSTER --domain DOMAIN command.
Please rerun or contact support.





 Error 1136 

The vSRX license file is found, but the contents are empty. Please rerun or contact support.





 Error 1137 

The vSRX license file cannot be read. Please rerun or contact support.





 Error 1138 

The vSRX license install has failed during the vSRX license configuration. Please rerun or contact support.





 Error 1139 

The vSRX configuration includes a tcp-mss setting on an interface. Remove the invalid configuration and rerun.





 Error 1140 

The vSRX configuration includes an unsupported configuration setting. Correct and/or remove the unsupported configuration setting and rerun. Refer to [Correcting Unsupported vSRX Configuration Commands](https://cloud.ibm.com/docs/vsrx?topic=vsrx-correcting-readiness-errorscorrecting-unsupported-configuration) for more information.





 Error 1141 

The vSRX was accessible but we were unable to determine which node is the primary.





 Error 1142 

The vSRX includes duplicate IPs in the interface section of the vSRX config. Remove the duplicate IPs from the config and rerun.





 Error 1143 

The gateway upgrade process failed with an unexpected exception. Contact IBM Support.





 Error 1145 

The vSRX license does not support IDP, but IDP policies and configurations were detected on the running vSRX. Remove the policies and configurations or install a vSRX license with IDP support such as the Content Security Bundle (CSB) and retry the operation. For details on configuration removal refer to [Correcting error 1145](https://cloud.ibm.com/docs/vsrx?topic=vsrx-correcting-readiness-errorscorrecting-1145) for more information.





 Error 1146 

The Ubuntu server's network switch does not support multicast, which is required by the gateway configuration. Contact IBM Support.





 Error 1147 

The vSRX configuration includes a url-pattern with invalid characters.
Because this certificate renewal process restarts the ordering node, and in the case of a TLS certificate renewal, the node can no longer participate in the application channel [consenter set](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-consenter), you need to pay particular attention to maintaining quorum on the application channel throughout this process. Before attempting these steps, and to avoid any interruption of service, ensure that you still have enough ordering nodes available to maintain quorum while this node is restarted or offline, in the case of a TLS certificate update.

The process to renew the enrollment certificate is the same for the ordering node as it is for the peers. But when you renew the ordering node TLS certificate, additional steps are required. Before proceeding, if you have a single-node ordering service and need to renew the TLS certificate, you should review [Considerations for a single node ordering service](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-manual-renewal-os1).



 Renew the certificates 



1. Open the ordering service and click the Ordering nodes tab. As ordering node certificates approach expiration, a warning icon is visible on their tile.
2. Open the ordering node you want to update. If automatic certificate renewal failed for the node, you should see a warning. Click the Settings icon.
3. Click Update certificates. You can renew either the Enrollment certificate or the TLS certificate or both, based on their expiration dates.
4. In the drop-down box for each certificate type, select Re-enroll certificate if the certificate has not expired, or Enroll certificate if it has already expired.
5. When you click Update certificates, the ordering node is restarted. Verify renewal is successful by clicking the certificate refresh button next to the Settings icon and examining the updated enrollment and TLS certificate expiration dates. Notice that the ordering node TLS certificate expiration date is in 15 years, so that renewal of this TLS certificate is not required again next year.