# Verification

The [Beyond Defaults](beyond-defaults) page covers the values you send into the
chart. This page covers the opposite direction. It shows how a deployer can see
what is actually running, including the material the deployment generates on its
own, such as service provider signing keys and SAML metadata.

## Values in the release

Render the manifests without installing, to preview the result of your
overrides:

```bash
helm template <Release.Name> cortex/cortex -f my-values.yaml -n <NAMESPACE>
```

After an install, inspect the values a release was actually given:

```bash
helm get values <Release.Name> -n <NAMESPACE>
```

See every manifest the release currently has applied, with the defaults and
overrides already resolved:

```bash
helm get manifest <Release.Name> -n <NAMESPACE>
```

## Secrets and certificates

The chart and its dependencies generate a number of Kubernetes secrets that hold
TLS certificates, SAML signing keys, and credentials. cert-manager issues the
service certificates, and CloudNativePG issues the ones for the Registry
database. None of this material appears in your values file.

| Secret | Type | Purpose |
| ------ | ---- | ------- |
| `proxy-tls` | TLS | Proxy HTTPS server certificate |
| `discovery-tls` | TLS | Discovery HTTPS server certificate |
| `registry-tls` | TLS | Registry HTTPS server certificate |
| `ldap-tls` | TLS | LDAP directory TLS certificate |
| `registry-sp-cert` | TLS | Registry Shibboleth service provider signing and encryption certificate |
| `discovery-sp-cert` | TLS | Discovery Shibboleth service provider signing and encryption certificate |
| `satosa-backend-cert` | TLS | Proxy SATOSA backend certificate, the proxy acting as a service provider |
| `satosa-frontend-cert` | TLS | Proxy SATOSA frontend certificate, the proxy acting as an identity provider |
| `registry-db-server` | TLS | Registry database server certificate |
| `registry-db-replication` | TLS | Registry database replication certificate |
| `registry-db-ca` | Opaque | Registry database certificate authority |
| `registry-db-credentials` | basic-auth | Registry database username and password |
| `registry-secret` | Opaque | Registry database password, email account password, and security salt |
| `satosa-secret` | Opaque | Proxy state encryption key and user identifier hash salt |
| `ldap-admin` | Opaque | LDAP administrator password |

### Reading secrets

Kubernetes stores secret data base64 encoded. To see every key of a secret with
its decoded value:

```bash
kubectl -n <NAMESPACE> get secret registry-secret \
  -o go-template='{{range $k,$v := .data}}{{printf "%s:\n" $k}}{{$v | base64decode}}{{"\n\n"}}{{end}}'
```

To read a single key, for example the database username and password from the
basic-auth secret:

```bash
kubectl -n <NAMESPACE> get secret registry-db-credentials -o jsonpath='{.data.username}' | base64 -d; echo
kubectl -n <NAMESPACE> get secret registry-db-credentials -o jsonpath='{.data.password}' | base64 -d; echo
```

The decoded output includes private keys and passwords in clear text, so run
these commands in a private shell and do not share the output.

### Checking certificates

A TLS secret holds the certificate under `tls.crt`. Decode it and pass it to
`openssl` to see who it was issued to, who signed it, and how long it is valid.
Reading the certificate is safe, because it is the public half of the pair.

```bash
kubectl -n <NAMESPACE> get secret registry-tls -o jsonpath='{.data.tls\.crt}' | base64 -d \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
```

The output shows the subject, which is who the certificate was issued to, the
issuer, which is who signed it, the `notBefore` and `notAfter` validity window,
and the DNS names the certificate covers. To check quickly whether a certificate
is still valid:

```bash
kubectl -n <NAMESPACE> get secret registry-tls -o jsonpath='{.data.tls\.crt}' | base64 -d \
  | openssl x509 -noout -checkend 0 && echo valid || echo expired
```
:::{tip}
A secret that holds a certificate authority, such as `registry-db-ca`, keeps its
certificate under `ca.crt` rather than `tls.crt`, so read that key instead.
:::

More details on the certificates in general can also be obtained by running the commands below;

```bash
kubectl -n <NAMESPACE> get certificate -o wide
kubectl -n <NAMESPACE> describe certificate registry-tls
```

:::{tip}
The Shibboleth and SATOSA signing certificates (`registry-sp-cert`,
`discovery-sp-cert`, `satosa-backend-cert`, and `satosa-frontend-cert`) are long lived
and self signed.
:::