OIDC client creation is not successful
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.
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-servicepod, etc. - OIDC client watcher pod is not Out Of Memory (OOM) or not in
the
crashloopbackstate.
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-watchercontainer 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
Steps to follow if certificate import is an issue
-
Login to the cluster by using
ocCLI. -
Save the content of shell as
updateJKS.sh. -
Run the shell script as
updateJKS.sh $namespace. Provide the namespace wherecommon-servicesare 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