Re: [openssl-users] Throwing in the towel on ENV for DN
On 08/18/2017 08:48 AM, Jeffrey Walton wrote: It is coming down that I would need a unique cnf for each cert type, rather than one per signing CA. Things just don't work well without prompting or very consistent DN content. So I am going to pull most of my. ENV. I am leaving it in for dir and SAN. I feel it is a bug that if in 'prompt = no' or -batch, if a DN object is empty (size 0), it should just be dropped. This is not an error condition. If this is a private PKI, then you can do things like that. I as not clear. meant one of the DN's objects like OU. If you have prompt = no and organizationalUnitName = It takes OU's size as zero and fails. This should not be an error condition, OU should be skipped just like if you had in the command (which I *KNOW* works): -subj "/CN=US/ST=MI/O= HTT Consulting/OU=/CN=Root CA" So I call it a bug. But I believe you need a distinguished name if you are following the RFCs. Maybe you can modify your script to stuff the principal name from the SAN in the DN somewhere. Next steps: complete basic setup for ecdsa pki and 802.1AR leaf. Publish on my website. Write up 'lessons learned' and post it here. I think there's a separate RFC or draft for 802.1AR, but I have not read it. Maybe part of the pain point is, OpenSSL is not aware of it. Its just using RFC 5280 (and to some extent, 6125). Maybe you should stop using the command line tools and code something up in C. Once you hit your stride using the C APIs, its easy to crank out certificates the way you want them. Jeff -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Throwing in the towel on ENV for DN
On 08/18/2017 08:46 AM, Salz, Rich via openssl-users wrote: This has been a long email thread. Can you open a github issue and summarize the improvements you think we should make? Thanks. And thanks for your patience! When I get through the "lessons learned" step, I will ask you how to open an issue. I just spent 2 hours fighting with variables and how to build the command line, until I realized that I have left "prompt = no" and made other changes and that where my error was... -subj on the command line does not seem to work if "prompt = no", or it is processed after taking what is in cnf. Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Throwing in the towel on ENV for DN
On Fri, Aug 18, 2017 at 08:48:07AM -0400, Jeffrey Walton wrote: > If this is a private PKI, then you can do things like that. > > But I believe you need a distinguished name if you are following the > RFCs. Maybe you can modify your script to stuff the principal name > from the SAN in the DN somewhere. The subject DN is allowed (and indeed recommended in RFC 5280) to be an empty RDN sequence (with the subject alt name extension marked critical, and holding the relevant names, in practice not marking critical works just as well). The issuer DN is the CA's subject name and is fixed, so not the OP's problem. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Throwing in the towel on ENV for DN
> It is coming down that I would need a unique cnf for each cert type, rather > than one per signing CA. Things just don't work well without prompting or > very consistent DN content. So I am going to pull most of my. ENV. I am > leaving it in for dir and SAN. > > I feel it is a bug that if in 'prompt = no' or -batch, if a DN object is > empty (size 0), it should just be dropped. This is not an error condition. If this is a private PKI, then you can do things like that. But I believe you need a distinguished name if you are following the RFCs. Maybe you can modify your script to stuff the principal name from the SAN in the DN somewhere. > Next steps: > > complete basic setup for ecdsa pki and 802.1AR leaf. Publish on my website. > Write up 'lessons learned' and post it here. I think there's a separate RFC or draft for 802.1AR, but I have not read it. Maybe part of the pain point is, OpenSSL is not aware of it. Its just using RFC 5280 (and to some extent, 6125). Maybe you should stop using the command line tools and code something up in C. Once you hit your stride using the C APIs, its easy to crank out certificates the way you want them. Jeff -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Throwing in the towel on ENV for DN
This has been a long email thread. Can you open a github issue and summarize the improvements you think we should make? Thanks. And thanks for your patience! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Throwing in the towel on ENV for DN
Jakob had it right On 08/17/2017 07:01 PM, Jakob Bohm wrote: Given all these problems with the Distinguished Name prompting mechanism, just add the -subject option to the req command line (using appropriate environment variables in the shell script). Enjoy Jakob It is coming down that I would need a unique cnf for each cert type, rather than one per signing CA. Things just don't work well without prompting or very consistent DN content. So I am going to pull most of my. ENV. I am leaving it in for dir and SAN. I feel it is a bug that if in 'prompt = no' or -batch, if a DN object is empty (size 0), it should just be dropped. This is not an error condition. I nice feature would be if a default is set, not to prompt for that object. Something like prompt = if no default Then I would use ENV to set the default values and let prompting go for objects like CN and UID. Also SAN is poorly handled and it has come out that this is a basic RFC requirement since '00! Next steps: complete basic setup for ecdsa pki and 802.1AR leaf. Publish on my website. Write up 'lessons learned' and post it here. Add CRL and OCSP support. Publish an IETF ID at least as an individual submission; offer this work to the IETF hackathon and workgroups like NETCONF, I2NSF, DOTS, ANIMA, and CORE. Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users