OIDC client creation is not successful

There can be many reasons that why the OIDC client creation is not successful, however, the few obvious reasons are listed following:

• Invalid client CR
• Associated pod is not running properly
• Issue with the dependent services, such as platform-auth-service pod, etc.
• OIDC client watcher pod is not Out Of Memory (OOM) or not in the crashloopback state.

If you have verified that the client CR is valid, associated pods are running properly or dependent services are also running properly and still the OIDC client creation is still not successful then the possible reason might be that the oidc-client-watcher is not able to connect with auth-service endpoint properly. This might be because of not having the correct certificate entry at the auth-service end.

Confirming the certificate import issue if oidc-client-watcher pod is not able to connect with auth-service endpoint properly

The following symptoms might confirm whether there is certificate import issue:

• If no status is available in the client CR after the client CR is created

• Also, the oidc-client-watcher container might show the similar error:

   oc logs $oidcclient-watcher-xxx -f
  

  Replace oidcclient-watcher-xxx with actual pod and instance names.

   {"level":"error","ts":1669062335.0758603,"logger":"controller-runtime.controller","msg":"Reconciler error","controller":"controller_oidc_client","request":"cap4ba-ns3/ibm-bts-oidc-client","error":"Error occurred during create oidc client regstration".
  

  Where, request name might vary.

In case you see this error, you can verify whether you are observing the error due to the certificate issue. If there are multiple platform-auth-service instances, you need to verify for all the instances by using the following command:

   oc login
   oc project $namespace
   oc exec -it $platform-auth-service-xxx /bin/bash
   cd /opt/ibm/wlp/output/defaultServer/resources/security
   keytool -v -list -keystore key.jks -alias default -storepass insecurePass

Replace the platform-auth-service-xxx with the platform-auth-service instance names. And, provide the namespace where common-services are installed.

If you find the default alias entry that contains the following information as Issuer and Owner, it means that the certificate import is an issue.

   Owner: OU=ISL, O=IBM India, L=BANGALORE, ST=KARNATAKA, C=IN
   Issuer: EMAILADDRESS=test@test.local, CN=CFSSL TEST Root CA, O=CFSSL TEST, L=San Francisco, ST=California, C=US

Note: If certificate import is the issue, see Steps to follow if certificate import is an issue. If certificate import is not the issue then there might be different reason that why the client creation is not happening and that needs to be checked.

Steps to follow if certificate import is an issue

1. Login to the cluster by using oc CLI.

2. Save the content of shell as updateJKS.sh.

3. Run the shell script as updateJKS.sh $namespace. Provide the namespace where common-services are installed.

oc project $1
for pod in $(oc get pod -o name | grep platform-auth-service);
do
  echo "Going to update jks for pod Name: ${pod}"
  oc exec -it ${pod} /bin/bash -c 'platform-auth-service' -- keytool -importkeystore -destkeystore /opt/ibm/wlp/output/defaultServer/resources/security/key.jks -srckeystore /certs/generated/platformauth-ks.p12 -srcstoretype pkcs12 -alias default -storepass insecurePass -srcstorepass insecurePass -noprompt
  echo  "Done"
done

Note: It is possible that after restart you might see the same issue so it is recommended to re-run the script.