Basic support for IoT devices (--dn-mode=device) #462
Conversation
|
While I appreciate the work here, did you consider the simple approach: |
|
As far as I can tell, your suggested solution would just include the device SN in the cert's CN. I wanted a more semantic approach, using the dedicated OID for storing the serial number. Am I making a confusion? |
No. You understood my question and gave your answer. That is why I asked. I'm still considering this.. |
# Conflicts: # easyrsa3/easyrsa
|
Linking #596 |
|
@Bogdan-Stancescu-RBC I am sorry to report this but I am really not happy to merge this pull request. The simple fact of the matter is that EasyRSA can provide a perfectly workable solution for you as is. In your method, you choose to abandon the extended name fields provided by It is perfectly suitable to use On top of that, EasyRSA does not need another functional However, I am prepared to add I have even prepared a patch for it. Introduce Demonstration: |
|
Thank you for taking the time to investigate this and work out a solution that's convenient for everyone. I had considered the IoT devices' certificates as very lightweight, almost disposable things, but upon consideration of your proposal I realized it's actually important for them to be attached to an organization – so in the end I think your solution is actually better than mine. Thank you again for your time and consideration! |
|
Thanks for your time and patience on this one. I'll add a credit in |
|
Unfortunately, using Closing this as: Original problem solved, full solution is out-of-scope for EasyRSA, at this time. Future pull requests welcome, if they work correctly. |
|
Re-opening-as: Feature request |
|
@Bogdan-Stancescu-RBC I found a suitable solution to your request. In This works the same way as the normal fields in If you find time to test then please let me know if/how it works for you, good feedback will expedite merging. Thanks |
|
@TinCanTech I'm afraid that doesn't suit my business case. I specifically need the serialNumber OID because I genuinely need to populate the device's immutable hardware SN in that field. Using anything else than the dedicated OID would result in semantic ambiguity. |
|
@Bogdan-Stancescu-RBC I don't see how the field name used to store your device serial number makes any difference to your external requirements. Using Your initial PR discarded the |
|
Now that I have a functional frame work, I can test this further and perhaps change to |
|
I'm very confused. I always thought OID 2.5.4.5 (part of the subject data, and distinct from the certificate SN) was meant specifically to identify the subject's (i.e. device's) serial number (not the certificate's). Why do you feel that would be ambiguous? |
|
For clarity, my only intention ever was to be able to issue certificates for IoT devices using EasyRSA, specifically because it's a very convenient toolset. I approached this by including the device's hardware serial number in the certificate in the most standard, semantically-identifiable, non-ambiguous manner I managed to identify. I might have approached the issue completely wrongly from a maintenance perspective in the context of EasyRSA, and I might be confused about specific technical details regarding X.509 certificates, but I never had any other objective. I'm happy with any technical solution that reaches those objectives. If we can't find one which also works with EasyRSA's maintainability/philosophical constraints I'll have to keep maintaining my own fork. Which is a PITA, and it widows the rest of the community of a functionality which I believe will gain traction as IoT devices become more mature security-wise. Regardless, I will be forever grateful to this community (and the OpenVPN community in general) for EasyRSA; it really taught me a lot and made my life a lot easier than having to deal with all of the complexity of openssl from day 1. |
|
For clarity on my-side; I have not made a final decision on this and your answer above does clear up some likely misconceptions I have .. I will spend some time digging into this further and see if a better (Industry standard) approach can be found. Thanks for your feedback and patience. |
|
Please see #599 |
LE: Also added a couple of concrete ways to download the sources in the online docs (the second commit).
Added basic support for IoT device certificates (
--dn-mode=device), which is basically the same as--dn-mode=ca_only, except it adds support for OID 2.5.4.5 (serialNumber) in the certificate's Subject. This commit should include all necessary changes for this feature, including in the inline documentation, online documentation, and appropriatevars.examplechanges.Test it: