Cluster Supply Chain shows not ready after enabling policy enforcement with scan 2.0

Products

• VMware Tanzu Platform - Kubernetes
• VMware Tanzu Platform - TAP

Issue/Introduction

after following the Enable policy enforcement procedure you see an error that looks like this

https://techdocs.broadcom.com/us/en/vmware-tanzu/standalone-components/tanzu-application-platform/1-12/tap/scst-scan-creating-scan-policy-template.html

 

Symptoms A

❯ k get csc
NAME                                          READY   REASON              AGE
source-test-scan-to-url-package-with-policy   False   TemplatesNotFound   29m

❯ k describe csc source-test-scan-to-url-package-with-policy
Status:
  Conditions:
    Last Transition Time:  2026-04-10T16:25:09Z
    Message:               did not find the template of the resource(s) [scan-policy-enforcement]
    Reason:                TemplatesNotFound
    Status:                False
    Type:                  TemplatesReady
    Last Transition Time:  2026-04-10T16:25:09Z
    Message:               did not find the template of the resource(s) [scan-policy-enforcement]
    Reason:                TemplatesNotFound
    Status:                False
    Type:                  Ready
  Observed Generation:     1
Events:                    <none>

Inspecting the pod logs from the build will show an error that looks like this

curl: (77) error setting certificate file: /var/cert/ca.crt 

 

Symptom B

In some cases you maybe past the above error symptoms and have reached the following error in the pod logs

 curl: (60) SSL certificate problem: unable to get local issuer certificate

 

 

Resolution

there were two documentation issues that have or will be addressed.  In the step "Set up Metadata Store credentials and scan policy"

https://techdocs.broadcom.com/us/en/vmware-tanzu/standalone-components/tanzu-application-platform/1-12/tap/scst-scan-creating-scan-policy-template.html#setup-credentials

For Symptom A ("curl: (77) error setting certificate file: /var/cert/ca.crt")

The documentation informs the reader to use caCert key which is correct for the manual secret creation. but when using namespace provisioner the system templates expect "ca.crt" key. 

secret not compatible with namespace provisioner

apiVersion: v1
data:
 caCrt: ${METADATA_STORE_CA_CERT}
kind: Secret
metadata:
 name: metadata-store-cert
type: Opaque

good secret to use with namespace provisioner

apiVersion: v1
data:
 ca.crt: ${METADATA_STORE_CA_CERT}
kind: Secret
metadata:
 name: metadata-store-cert
type: Opaque

If you encounter this symptom then you can simply leave the caCrt key and append a new key ca.crt to your secret.  Make sure to update your gitops repo with these changes so the namespace provisioner will update the secrets. 

 

For Symptom B (" curl: (60) SSL certificate problem: unable to get local issuer certificate")

This could happen if you are using a multi cluster setup.  The documentation in step 1 of set up credentials using namespace provisioner is telling you to get the ca from the app-tls-cert secret.  This is ok for non multi-cluster deployments

METADATA_STORE_CA_CERT=$(kubectl get secret -n metadata-store app-tls-cert -o json | jq -r ".data.\"ca.crt\"")

for multicluster deployments you will get the ca cert from the "ingress-cert" and update your gitops secret for ca.crt just like in Symptom A

METADATA_STORE_CA_CERT=$(kubectl get secret -n metadata-store ingress-cert -o json | jq -r ".data.\"ca.crt\"")