Besides linux Servers, what other servers we can able to issue , renew and revoke the Certificates using Vault PKI. I was not able to find these details in documentation anywhere…
Do they support issuing, renewing and revoking certs on below servers / platforms as well ?
DB’s such as Oracle, Couchdb, Postgres. mongodb
Windows servers, vcenter server, vsphere hosts
Kafka, Openshift (redhat), Network Appliances such as (F5, Netscaler), Storage Nodes (Netapp)
Cert is a cert it isn’t OS bound. There are many many different certs but you can use openssl (for example) to convert or manipulate certs into other formats.
You can use the Vault API from any client you wish, again not OS bound.
You can use the Vault CLI from the OSs that they have been published to or you can take the code from github and compile it on any machine that has a go-lang compiler.
You need “A” backend storage solution to even start Vault (excluding dev mode which is in-memory only); Raft (aka integrated storage) is one of those options.
On my client server, generated private key and CSR File to submit.
openssl req -new -newkey rsa:2048 -nodes -keyout private.key -out server.csr
Can I able to use the server.csr to issue the cert for this server via Vault PKI. I dont want vault to create my private key. we have scenarios where we want to use client generated private keys and CSR…
Are there commands to add .csr file while generting a cert via Vault API ?
Issue #2
I was able to revoke the cert via API, Web UI and also Vault cli.
I was able to see that its revoked on Vault side.
When i check on the Web Server / Client side, I still see that the certificate is showing as valid. It doesnt show its revoked. I tested this in both Firefox and Chrome.
Certificate revocation is harder… For it to work at all, you have to have set up a suitable CRL URL before creating the certificate to be revoked… And even then, Chrome does not use CRLs out of the box at all anyway:
Online (i.e. OCSP and CRL) checks are not, generally, performed by Chrome.
My personal read on the status of certificate revocation today, is that outside of niche use-cases where you control all possible client software, you should just give up on it and use frequently replaced short-lived certificates instead.