Certificate type entry deprecated
Hi,
I tried to search the forums, and the documentation, but I can't find "how-to" handle the deprecation of the Certificate Entry Type.
We use it extensively because the certificate is available along with its private key and password.
With the new type it does not seem possible to retrieve the password once it has been added. It also seems far more cumbersome to save (export) the certificate.
In general it seems the usability has gone down.
Can we keep using the deprecated Certificate Entry Type? Or is there another way to achieve the functionality that we cherish with the deprecated type?
The x.509 type seems less userfriendly. If i want to save the certificate it prompts for the password, which cannot be stored in this entry type, additionally, while trying to save it, you cannot change focus to RDM to get the password from another entry.
Please don't deprecate the Certificate Entry Type
All Comments (2)
Hello
I understand your concerns here, but I also think there might be some misunderstanding.
First, the old Certificate (Document) type is deprecated yes but it remains in the product for now. I'd have to talk with the RDM Windows team about its eventual removal, but at the moment it costs us nothing to keep it. It's more that at this point we generally won't fix bugs or add features, and we'll try to guide people to use the X.509 Credential type. I don't know if or when it will go away but as long as it's meeting workflows that the X.509 entry can't provide, it will stay.
To explain the technical background: the Certificate (Document) entry is just a binary blob storage, with some manually associated metadata like an optional password and expiration date. RDM does not understand the data - you could really attach any kind of file here - which means the data itself is not usable to RDM. The metadata has to be hand maintained; there is nothing that fixes the expiration date in the entry to the actual document and these would often drift over time. Users would update the certificate file and not the password, leading to a broken entry and an unrecoverable certificate simply because there was no way to enforce synchronicity here.
When you attach data to an X.509 credential entry, RDM parses the certificate and converts it to a standardized format for storage (PKCS12). The certificate data is re-encrypted with strong crypto and a new strong password, known only to RDM. As such we can present the full certificate data to the user without needing to maintain metadata separately, RDM can understand this data internally because it is able to decrypt the certificate, and most importantly, RDM can use the certificate in places it's helpful (like, authentication).
Here's the key misunderstanding as I understand your post: when you attach the certificate, RDM re-encrypts it with a new password that only RDM knows. When you export the certificate from RDM, it's exported as a new certificate file. If you choose an encrypted format, RDM isn't asking you for the password the certificate it holds - RDM knows that - it's asking you to provide a new password for the new certificate file it's providing you.
In that sense it's still a bit more cumbersome than the Certificate (Document) entry I agree, but the trade-off at that point is more flexibility to handle different certificate types and import or export in the format you need.
Can I ask, what your workflow is that you hold a certificate in RDM and regularly require access to the certificate and it's private key outside of RDM? It's possible that I can suggest a better way of achieving what you want inside RDM using the X.509 credential, equally it's possible that we can add some improvements to benefit you and other users.
Please, let me know if something isn't clear or you have further questions
Kind regards,
Richard Markievicz
Hi Richard,
Thank you so much for the explanation!
I had just updated to the new version for everyone and a coworker started screaming that this was "garbage" (his words) and I didn't have the time to deep dive into how it was before and after. I did have a feeling that his complaints didn't make sense. Because, why would you make the certificates unexportable? I just didn't have time to find the solution.
But this makes great sense! I will relay the information to them!
Thanks again for your time!
Best regards
David