I'd suggest reading up a bit more about X.509 CSRs and Certificates before assuming that private credentials are being transmitted in the clear.
I appreciate the somewhat misguided feedback because you did point out that the rationale isn't clear enough. The rest of it is questionable though.
I'd suggest reading up a bit more about X.509 CSRs and Certificates before assuming that private credentials are being transmitted in the clear.
I appreciate the somewhat misguided feedback because you did point out that the rationale isn't clear enough. The rest of it is questionable though.
Bifrost CA server is a plain HTTP server that responds to X.509 Certificate Signing Requests (CSRs) sent via POST requests. The server validates CSRs, signs them, and returns signed certificates to clients.
and also mentioning how operators can secure access to the server.
Also it says:
Bifrost recognises clients by their ECDSA P-256 key pairs. A client’s UUID is the hash of the public key and the namespace. The namespace is any UUID that identifies a domain or application.
You __REALLY__ need to read up on x.509.
You can't fake the UUID in mTLS because you need the actual private key to be present with the client when it makes a connection to the server. There's no way to fake this in TLS.
> Creating a CSR creats my private key for the CSR...
Not really sure what's going on here tbh.
Yeah... No. You create a public/private key pair and the CSR CONTAINS that public key together with additional information.
>Not really sure what's going on here tbh.
I'm not surprised. Go read up on this stuff.
The CSR contains the digital signature of the public key that is requesting the certificate. So you absolutely need the private key to create a CSR. How would you create a CSR with just a public key?
Do you really not know what you're talking about or are you trolling at this point?
Yeah, go read it:
The
certification request information consists of the entity's
distinguished name, the entity's public key, and a set of attributes
providing other information about the entity.
I understand the server running on http only has the possibility in mind that there is a reverse proxy that terminates TLS. That’s fine. Running the server in plain http I’m having problems because the identifying credentials are transfered in plain text, visible for anyone that can monitor the network traffic.
Running something like this inside a DC where, in theory, no third party has access to the server or network may be fine as well, but the problem you’re trying to solve here, I don’t see it.
The only way to revoke acces in an X.509 environment is by revoking the client’s certificate unless you use some other means to identify the client, which in turn renders X.509 client authentication useless.
And using a CRL, even an incremental one, requires the server and the client to periodically fetch this file. Even with one minute intervals, there’s a one minute window were a compromised client can acccess the services and cause damage.
Also it seems that your stateless server neither creates a log of created certificates, for traceability, nor a CRL that it offers via HTTP. So w/o CRL you’re handing out certificates that you have zero control over.
I don’t know if that’s what you want, not even in a closed environment.
Everything you do, can be done with the help of a tab separated text file:
and then the clients just set a HTTP-Header with their UUID.The thing here is: You're not just not solving a problem, you're creating ten new ones.