Show me the curl requests to request ssl certificates to an hashicorp vault pki, and then configure an openshift route with them using reencrypt
GPT-5 mini:
Below are concise curl examples showing (A) requesting an X.509 certificate from a HashiCorp Vault PKI role and (B) retrieving the issued cert, private key, and CA chain, and (C) creating an OpenShift Route in reencrypt termination mode using those artifacts. Assumptions made (reasonable defaults):
- Vault address: https://vault.example.com
- Vault token: VAULT_TOKEN (replace)
- PKI mount path: pki (so endpoints under /v1/pki)
- PKI role name: my-role
- Certificate common name: app.example.com
- OpenShift API server: https://openshift.example.com:6443
- OpenShift token: OC_TOKEN (replace)
- OpenShift project/namespace: myproject
- Route name: my-route
- You have jq and base64 available locally for minor processing.
1) Request certificate from Vault (generate private key + CSR server-side using role)
- This requests a certificate for CN=app.example.com valid 90 days:
curl -sSK -H "X-Vault-Token: $VAULT_TOKEN" -X POST https://vault.example.com/v1/pki/issue/my-role -d '{ "common_name": "app.example.com", "ttl": "2160h" }' | jq .
Response fields of interest in JSON: data.certificate, data.issuing_ca (or data.ca_chain[]), data.private_key
2) Extract certificate, private key, and CA chain to files (pipe from prior command)
curl -sSK -H "X-Vault-Token: $VAULT_TOKEN" -X POST https://vault.example.com/v1/pki/issue/my-role -d '{ "common_name": "app.example.com", "ttl": "2160h" }' | jq -r '.data.certificate' > cert.pem
curl -sSK -H "X-Vault-Token: $VAULT_TOKEN" -X POST https://vault.example.com/v1/pki/issue/my-role -d '{ "common_name": "app.example.com", "ttl": "2160h" }' | jq -r '.data.private_key' > key.pem
- If CA chain is returned as array, prefer ca_chain[0] or issuing_ca
curl -sSK -H "X-Vault-Token: $VAULT_TOKEN" -X POST https://vault.example.com/v1/pki/issue/my-role -d '{ "common_name": "app.example.com", "ttl": "2160h" }' | jq -r '.data.ca_chain[0] // .data.issuing_ca' > ca.pem
(Option: do the Vault request once and split outputs; above shows separate calls for clarity. To do it once:)
resp=$(curl -sSK -H "X-Vault-Token: $VAULT_TOKEN" -X POST https://vault.example.com/v1/pki/issue/my-role -d '{"common_name":"app.example.com","ttl":"2160h"}')
echo "$resp" | jq -r '.data.certificate' > cert.pem
echo "$resp" | jq -r '.data.private_key' > key.pem
echo "$resp" | jq -r '.data.ca_chain[0] // .data.issuing_ca' > ca.pem
3) Create an OpenShift TLS secret containing cert+key+ca
OpenShift requires a TLS secret with tls.crt (certificate + chain) and tls.key (private key). Combine cert + CA chain into tls.crt:
cat cert.pem ca.pem > tls.crt
cat key.pem > tls.key
Encode and create via oc (preferred) or curl to the API. Using curl to Kubernetes API:
- base64-encode
CRT_B64=$(base64 -w0 < tls.crt)
KEY_B64=$(base64 -w0 < tls.key)
- Secret manifest (JSON)
read -r -d '' SECRET_JSON «EOF
{
"apiVersion": "v1",
"kind": "Secret",
"metadata": { "name": "my-route-tls", "namespace": "myproject" },
"type": "kubernetes.io/tls",
"data": {
"tls.crt": "$CRT_B64",
"tls.key": "$KEY_B64"
}
}
EOF
curl -sSK -H "Authorization: Bearer $OC_TOKEN" -H "Content-Type: application/json" -X POST https://openshift.example.com:6443/api/v1/namespaces/myproject/secrets -d "$SECRET_JSON" | jq .
(If secret exists, use PUT to replace: …/secrets/my-route-tls)
4) Create OpenShift Route with reencrypt termination pointing to that secret
The Route must reference the secret name in tls.secretName and use termination: Reencrypt. Example manifest (use API route.openshift.io/v1):
read -r -d '' ROUTE_JSON «EOF
{
"apiVersion": "route.openshift.io/v1",
"kind": "Route",
"metadata": { "name": "my-route", "namespace": "myproject" },
"spec": {
"host": "app.example.com",
"to": { "kind": "Service", "name": "my-backend-svc", "weight": 100 },
"port": { "targetPort": "https" },
"tls": {
"termination": "reencrypt",
"insecureEdgeTerminationPolicy": "Redirect",
"certificate": "$(awk 'BEGIN{RS=\"\"} {print}' tls.crt | sed 's/$/\\n/' | sed -e ':a;N;$!ba;s/\"/\\\\"/g')",
"key": "$(awk 'BEGIN{RS=\"\"} {print}' tls.key | sed 's/$/\\n/' | sed -e ':a;N;$!ba;s/\"/\\\\"/g')",
"caCertificate": "$(awk 'BEGIN{RS=\"\"} {print}' ca.pem | sed 's/$/\\n/' | sed -e ':a;N;$!ba;s/\"/\\\\"/g')",
"destinationCACertificate": "$(awk 'BEGIN{RS=\"\"} {print}' ca.pem | sed 's/$/\\n/' | sed -e ':a;N;$!ba;s/\"/\\\\"/g')"
}
}
}
EOF
curl -sSK -H "Authorization: Bearer $OC_TOKEN" -H "Content-Type: application/json" -X POST https://openshift.example.com:6443/apis/route.openshift.io/v1/namespaces/myproject/routes -d "$ROUTE_JSON" | jq .
Notes on fields:
- termination: "reencrypt" tells the router to use TLS to the backend.
- certificate/key/caCertificate in the Route tls block populate edge cert presented to clients by the router (optional if you want router to present your cert).
- destinationCACertificate (or service CA) is used by the router to validate the backend service certificate. Provide the CA that issued the backend cert.
- If you instead stored the secret and want the router to use the secret automatically, OpenShift routers typically use tls.secretName on the route (older behavior); if your cluster supports that, set "tls": {"termination":"reencrypt","certificate":…, …} as above or reference the secret depending on platform/version.
Alternative simpler flow (common):
- Create TLS secret as step 3.
- Create route that references the secret name (some OpenShift versions support tls.secretName):
read -r -d '' ROUTE_JSON2 «EOF
{
"apiVersion": "route.openshift.io/v1",
"kind": "Route",
"metadata": { "name": "my-route", "namespace": "myproject" },
"spec": {
"host": "app.example.com",
"to": { "kind": "Service", "name": "my-backend-svc" },
"tls": {
"termination": "reencrypt",
"insecureEdgeTerminationPolicy": "Redirect",
"certificate": "",
"key": "",
"caCertificate": "",
"destinationCACertificate": ""
}
}
}
EOF
- If your OpenShift supports referencing the secret by name, set tls.secretName: "my-route-tls" in spec.tls.
Practical tips:
- Ensure backend service serves HTTPS and its cert is signed by the CA you provided as destinationCACertificate.
- Use oc create secret tls and oc create route if you have oc client (much simpler).
- Replace tokens/hosts/paths with real values and secure tokens.
If you want, I can produce a ready-to-run script that performs the full flow (one Vault request, creates secret, creates route) for your exact Vault/OpenShift endpoints and role—provide the values and whether you prefer oc vs curl.