slotain
Minnow
It's bigger than a regular hat. It's funny.
Posts: 19 
|
Post by slotain on May 26, 2023 16:21:09 GMT
There's a white paper that describes Certificate Management www.dmtf.org/sites/default/files/standards/documents/DSP2059_1.1.0.pdfIn this paper, DELETE is used to remove a certificate. In this case, is deleting the Private Key, left up to the implementation? Installing a certificate and private key is a valid action, assuming the user's request payload to the Redfish API contains a concatenated CERT and KEY. Of course, reading the endpoint would return only certificate details (if one exists), and deleting the certificate should (definitely) remove the certificate (and so reading the endpoint would be HTTP 404). I suppose if we logically extend the entire workflow, further generations of a CSR would fail if we in fact did not have a private key because of the delete operation. There is no way of knowing if one exists, I suppose, because there are no endpoints that tell you there's a private key available for signing requests. You'd just have to attempt to sign a new one. Please, correct me where I'm wrong here. Basically, I'm trying to figure out a best practice for my Redfish implementation in this specific scenario: if my user executes a DELETE method to the certificate endpoint, do they also have the assumption that the PRIVATE KEY is deleted? Does my user expect me to NEVER delete the private key? Would the action I take in my Redfish implementation in a DELETE scenario depend on whether they installed both a Certificate and Private Key in the same "installation scenario"? |
|
slotain
Minnow
It's bigger than a regular hat. It's funny.
Posts: 19
|
Post by slotain on May 26, 2023 16:34:54 GMT
Perhaps my original post contains a confused understanding of how the GenerateCSR action would work.
The private key inside the certificate at location "/redfish/v1/Managers/BMC/NetworkProtocol/HTTPS/Certificates/1"...
A) should be used to generate new certificates in GenerateCSR actions, or
B) not be used to generate? because the private key used to generate is signed by a CA and is completely separate and private to the Redfish service?
C) sometimes, depending if the user uploaded it?
|
|
|
|
Post by mraineri on May 26, 2023 16:43:42 GMT
I would expect that when you delete the certificate, it would also delete the underlying private key. To me this is obvious since it doesn't seem useful to keep the private key around when the certificate is deleted, but perhaps others don't jump to that same conclusion and it's worth clarifying.
Yes, it's certainly valid to install a certificate with the private key concatenated. The primary use case for this is when the public-private key pair is generated off the manager and the private key needs to be transferred to the manager. Ideally a user would generate the key pair with the GenerateCSR action, the the manager would keep the private key internal, and match the private key when the client comes back with the signed certificate. This does leave the question open for how long to keep the private key in case the user never returns with the signed certificate... Would you also delete the old private key on a subsequent GenerateCSR request? Maybe, but what if they user really is trying to create multiple certificates for the same collection...
I think in the short term for your immediate question, I would recommend the private key is deleted when the certificate is also deleted (assuming the private key is tracked by the service); this is reasonable behavior in my opinion. However, keep in mind there are cases where the certificate on the service will not have the accompanying private key, such as when the service has a certificate to compare against a remote server to check its identity. In these cases, the service will never have the matching private key.
|
|
|
|
Post by mraineri on May 26, 2023 16:52:11 GMT
Specifically for the "/redfish/v1/Managers/BMC/NetworkProtocol/HTTPS/Certificates", there are two possible workflows I've seen. First is the more recommended path (where the private key is kept inside the manager and never exposed to anyone):
- User invokes the GenerateCSR action
- Manager generates the public-private key pair, responds with the CSR string, and keeps the private key internal to itself
- User takes the CSR string and has their CA produce a signed certificate
- User performs the ReplaceCertificate action to atomically delete the existing HTTPS certificate (and private key) and install the newly created one from the previous step
- Manager matches the private key in step 2 with the new certificate for the web server
The other path can be the user creates the key pair outside of the manager (such as their own laptop), and the GenerateCSR action is never used. This goes against some security best practices since this requires transmitting the private key, but some users choose to do this anyway:
- User generates a public-private key pair. They might use this to create a self-signed certificate, or create a CSR for a CA to sign.
- User performs the ReplaceCertificate action to atomically delete the existing HTTPS certificate (and private key) and install the newly created one from the previous step. The private key is also part of the CertificateString property in the request.
|
|
|
|
Post by mraineri on May 26, 2023 17:04:09 GMT
The reason I mention using ReplaceCertificate for this particular example rather than discrete DELETE/POST operations is because you might have some logically odd corner cases with deleting your service's HTTPS certificate. For example, when you delete the certificate, do you leave the collection empty? How would your service react to starting up if there is no HTTPS certificate to be found? Do you generate a new certificate underneath the covers? Using ReplaceCertificate here helps eliminate the need for solving these corner cases and gives users a bit of determinism with different implementations.
|
|
slotain
Minnow
It's bigger than a regular hat. It's funny.
Posts: 19
|
Post by slotain on May 26, 2023 21:45:17 GMT
Thanks for the workflow; the step-by-step really helps with my confusion about what the GenerateCSR action is accomplishing.
I'll have to come back when I'm armed and dangerous with better knowledge. Thanks, as always, your assistance is very helpful!
|
|
