Re: [openssl-users] Throwing in the towel on ENV for DN

2017-08-18 Thread Robert Moskowitz



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

2017-08-18 Thread Robert Moskowitz



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

2017-08-18 Thread Viktor Dukhovni
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

2017-08-18 Thread Jeffrey Walton
> 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

2017-08-18 Thread Salz, Rich via openssl-users
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

2017-08-18 Thread Robert Moskowitz

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