[openssl-users] FINAL simpler solution - Re: Solved - Re: Cant get the subjectALtName inot the root cert

[Robert Moskowitz]

I just had to ask Dr. Google the right question:

openssl subjectaltname in a selfsigned certificate

Afterall, a root cert is a selfsigned cert.

And I learned to put SAN in the [ v3_ca ] section, rather than the [ req 
] section then all it takes is what I already had:


openssl req -config openssl-root.cnf -key private/ca.key.pem \
  -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem



On 08/17/2017 09:52 PM, Robert Moskowitz wrote:

It IS working with -selfsign.  So this step is done.

openssl ca -config openssl-root.cnf -extensions v3_ca -days 7300 
-notext -md sha256 \

  -selfsign -in csr/ca.csr.pem -out certs/ca.cert.pem

openssl x509 -in certs/ca.cert.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
87:b5:1d:03:12:a9:f3:fa
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=MI, O=HTT Consulting, CN=Root CA
Validity
Not Before: Aug 18 01:50:19 2017 GMT
Not After : Aug 13 01:50:19 2037 GMT
Subject: C=US, ST=MI, O=HTT Consulting, CN=Root CA
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:03:ee:4a:51:17:df:50:2b:bc:69:63:b5:03:90:
b5:ed:cf:d5:67:16:94:46:9c:ca:5b:1c:87:d0:81:
18:04:bf:5a:c0:00:4e:90:4b:fb:2e:17:1c:aa:42:
1e:9e:bd:be:ba:d7:f8:6c:55:24:b2:91:da:61:9c:
66:b4:03:a5:93
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Subject Key Identifier:
D5:09:1A:48:F2:D8:F8:30:46:26:38:78:C8:C2:C5:CD:01:A7:1D:57
X509v3 Authority Key Identifier:
keyid:D5:09:1A:48:F2:D8:F8:30:46:26:38:78:C8:C2:C5:CD:01:A7:1D:57

X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Subject Alternative Name:
email:postmas...@htt-consult.com
Signature Algorithm: ecdsa-with-SHA256
 30:46:02:21:00:ed:b6:ea:93:b5:df:b2:30:fe:17:fc:a6:fa:
 0e:c1:08:82:9a:84:59:a9:a6:5c:50:23:66:72:c0:da:7a:18:
 5b:02:21:00:8b:f1:52:ea:dd:44:88:a6:ee:43:cd:29:52:e4:
 27:57:ee:52:a2:47:86:6f:9e:11:9d:7d:72:a5:08:82:8f:14



On 08/17/2017 09:23 PM, Robert Moskowitz wrote:
NO does not work.  It worked because I had the old root CA cert 
there.  Without it it fails.


I tried adding -selfsign and that did something, but did not create a 
trusted cert...



On 08/17/2017 08:44 PM, Robert Moskowitz wrote:

Kind of...

Does not put SAN in CA cert:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
  -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem


Does put SAN in CA cert:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
  -new -sha256 -extensions v3_ca -out csr/ca.csr.pem

openssl ca -config openssl-root.cnf -extensions v3_ca -days 7300 
-notext -md sha256 \

  -in csr/ca.csr.pem -out certs/ca.cert.pem

Interesting that the single step does not work, but the 2 step doesn.

Do I need -extensions v3_ca in both commands?  Plus sha256 in both? 
Could benefit from some refinement.  Or getting the 1 step working.


Good enough for now!

Bob


On 08/17/2017 06:38 PM, Jeffrey Walton wrote:
On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz 
 wrote:
I guess I am making progress.  I am not getting SAN into the root 
cert.  my

cnf has in it:

[ req ]
# Options for the `req` tool (`man req`).
default_bits= 2048
prompt  = no
distinguished_name  = req_distinguished_name
string_mask = utf8only
req_extensions  = req_ext

[ req_ext ]
#subjectAltName = email:$ENV::adminemail
#subjectAltName = email:ad...@htt-consult.com
subjectAltName = IP:192.168.24.1

I tried all three above alternatives for SAN.  No SAN in the root 
cert

created with:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
   -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem


Thanks for any insight.

This type of cnf worked for creating a CSR and with the copy 
option the SAN

made it into the cert.

It looks a bit unusual for a Root CA.

As far as signing the CSR, you need

 copy_extensions = copy

Jeff








--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Solved - Re: Cant get the subjectALtName inot the root cert

[Robert Moskowitz]

It IS working with -selfsign.  So this step is done.

openssl ca -config openssl-root.cnf -extensions v3_ca -days 7300 -notext 
-md sha256 \

  -selfsign -in csr/ca.csr.pem -out certs/ca.cert.pem

openssl x509 -in certs/ca.cert.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
87:b5:1d:03:12:a9:f3:fa
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=MI, O=HTT Consulting, CN=Root CA
Validity
Not Before: Aug 18 01:50:19 2017 GMT
Not After : Aug 13 01:50:19 2037 GMT
Subject: C=US, ST=MI, O=HTT Consulting, CN=Root CA
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:03:ee:4a:51:17:df:50:2b:bc:69:63:b5:03:90:
b5:ed:cf:d5:67:16:94:46:9c:ca:5b:1c:87:d0:81:
18:04:bf:5a:c0:00:4e:90:4b:fb:2e:17:1c:aa:42:
1e:9e:bd:be:ba:d7:f8:6c:55:24:b2:91:da:61:9c:
66:b4:03:a5:93
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Subject Key Identifier:
D5:09:1A:48:F2:D8:F8:30:46:26:38:78:C8:C2:C5:CD:01:A7:1D:57
X509v3 Authority Key Identifier:
keyid:D5:09:1A:48:F2:D8:F8:30:46:26:38:78:C8:C2:C5:CD:01:A7:1D:57

X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Subject Alternative Name:
email:postmas...@htt-consult.com
Signature Algorithm: ecdsa-with-SHA256
 30:46:02:21:00:ed:b6:ea:93:b5:df:b2:30:fe:17:fc:a6:fa:
 0e:c1:08:82:9a:84:59:a9:a6:5c:50:23:66:72:c0:da:7a:18:
 5b:02:21:00:8b:f1:52:ea:dd:44:88:a6:ee:43:cd:29:52:e4:
 27:57:ee:52:a2:47:86:6f:9e:11:9d:7d:72:a5:08:82:8f:14



On 08/17/2017 09:23 PM, Robert Moskowitz wrote:
NO does not work.  It worked because I had the old root CA cert 
there.  Without it it fails.


I tried adding -selfsign and that did something, but did not create a 
trusted cert...



On 08/17/2017 08:44 PM, Robert Moskowitz wrote:

Kind of...

Does not put SAN in CA cert:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
  -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem


Does put SAN in CA cert:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
  -new -sha256 -extensions v3_ca -out csr/ca.csr.pem

openssl ca -config openssl-root.cnf -extensions v3_ca -days 7300 
-notext -md sha256 \

  -in csr/ca.csr.pem -out certs/ca.cert.pem

Interesting that the single step does not work, but the 2 step doesn.

Do I need -extensions v3_ca in both commands?  Plus sha256 in both? 
Could benefit from some refinement.  Or getting the 1 step working.


Good enough for now!

Bob


On 08/17/2017 06:38 PM, Jeffrey Walton wrote:
On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz 
 wrote:
I guess I am making progress.  I am not getting SAN into the root 
cert.  my

cnf has in it:

[ req ]
# Options for the `req` tool (`man req`).
default_bits= 2048
prompt  = no
distinguished_name  = req_distinguished_name
string_mask = utf8only
req_extensions  = req_ext

[ req_ext ]
#subjectAltName = email:$ENV::adminemail
#subjectAltName = email:ad...@htt-consult.com
subjectAltName = IP:192.168.24.1

I tried all three above alternatives for SAN.  No SAN in the root cert
created with:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
   -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem


Thanks for any insight.

This type of cnf worked for creating a CSR and with the copy option 
the SAN

made it into the cert.

It looks a bit unusual for a Root CA.

As far as signing the CSR, you need

 copy_extensions = copy

Jeff






--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Solved - Re: Cant get the subjectALtName inot the root cert

[Robert Moskowitz]

NO does not work.  It worked because I had the old root CA cert there.  
Without it it fails.


I tried adding -selfsign and that did something, but did not create a 
trusted cert...



On 08/17/2017 08:44 PM, Robert Moskowitz wrote:

Kind of...

Does not put SAN in CA cert:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
  -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem


Does put SAN in CA cert:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
  -new -sha256 -extensions v3_ca -out csr/ca.csr.pem

openssl ca -config openssl-root.cnf -extensions v3_ca -days 7300 
-notext -md sha256 \

  -in csr/ca.csr.pem -out certs/ca.cert.pem

Interesting that the single step does not work, but the 2 step doesn.

Do I need -extensions v3_ca in both commands?  Plus sha256 in both? 
Could benefit from some refinement.  Or getting the 1 step working.


Good enough for now!

Bob


On 08/17/2017 06:38 PM, Jeffrey Walton wrote:
On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz 
 wrote:
I guess I am making progress.  I am not getting SAN into the root 
cert.  my

cnf has in it:

[ req ]
# Options for the `req` tool (`man req`).
default_bits= 2048
prompt  = no
distinguished_name  = req_distinguished_name
string_mask = utf8only
req_extensions  = req_ext

[ req_ext ]
#subjectAltName = email:$ENV::adminemail
#subjectAltName = email:ad...@htt-consult.com
subjectAltName = IP:192.168.24.1

I tried all three above alternatives for SAN.  No SAN in the root cert
created with:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
   -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem


Thanks for any insight.

This type of cnf worked for creating a CSR and with the copy option 
the SAN

made it into the cert.

It looks a bit unusual for a Root CA.

As far as signing the CSR, you need

 copy_extensions = copy

Jeff




--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Solved - Re: Cant get the subjectALtName inot the root cert

[Robert Moskowitz]

Kind of...

Does not put SAN in CA cert:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
  -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem


Does put SAN in CA cert:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
  -new -sha256 -extensions v3_ca -out csr/ca.csr.pem

openssl ca -config openssl-root.cnf -extensions v3_ca -days 7300 -notext 
-md sha256 \

  -in csr/ca.csr.pem -out certs/ca.cert.pem

Interesting that the single step does not work, but the 2 step doesn.

Do I need -extensions v3_ca in both commands?  Plus sha256 in both? 
Could benefit from some refinement.  Or getting the 1 step working.


Good enough for now!

Bob


On 08/17/2017 06:38 PM, Jeffrey Walton wrote:

On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz  wrote:

I guess I am making progress.  I am not getting SAN into the root cert.  my
cnf has in it:

[ req ]
# Options for the `req` tool (`man req`).
default_bits= 2048
prompt  = no
distinguished_name  = req_distinguished_name
string_mask = utf8only
req_extensions  = req_ext

[ req_ext ]
#subjectAltName = email:$ENV::adminemail
#subjectAltName = email:ad...@htt-consult.com
subjectAltName = IP:192.168.24.1

I tried all three above alternatives for SAN.  No SAN in the root cert
created with:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
   -new -x509 -days 7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem

Thanks for any insight.

This type of cnf worked for creating a CSR and with the copy option the SAN
made it into the cert.

It looks a bit unusual for a Root CA.

As far as signing the CSR, you need

 copy_extensions = copy

Jeff


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant seem to get prompt no to work

[Robert Moskowitz]

On 08/17/2017 07:01 PM, Jakob Bohm wrote:

On 18/08/2017 00:09, Robert Moskowitz wrote:



On 08/17/2017 05:38 PM, Salz, Rich wrote:

declare -x organizationalUnitName=""
routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:151:minsize=1
You are setting an empty OU.  You should not set it and see if 
that works


organizationalUnitName = "."  puts a . in it.  So I have to figure 
out a way to drop that line from the config.


like if a field is not needed:

sed -i -e "s/^organizationalUnitName/#organizationalUnitName/w 
/dev/stdout" openssl-root.cnf



But this is not quite right.  I have to find the one that has ENV in 
it.  I DO have an example of one such to use...




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).


Always an option, Jakob.  I have done this in the past for my 
self-signed certs.  I am trying the config approach now.  But I may step 
back...


I AM making my CA certs.  With a SAN caviat in the root cert.

Slow progress.

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant get the subjectALtName inot the root cert

[Robert Moskowitz]

On 08/17/2017 06:38 PM, Jeffrey Walton wrote:

On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz  wrote:

I guess I am making progress.  I am not getting SAN into the root cert.  my
cnf has in it:

[ req ]
# Options for the `req` tool (`man req`).
default_bits= 2048
prompt  = no
distinguished_name  = req_distinguished_name
string_mask = utf8only
req_extensions  = req_ext

[ req_ext ]
#subjectAltName = email:$ENV::adminemail
#subjectAltName = email:ad...@htt-consult.com
subjectAltName = IP:192.168.24.1

I tried all three above alternatives for SAN.  No SAN in the root cert
created with:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
   -new -x509 -days 7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem

Thanks for any insight.

This type of cnf worked for creating a CSR and with the copy option the SAN
made it into the cert.

It looks a bit unusual for a Root CA.

As far as signing the CSR, you need

 copy_extensions = copy


I have that in the [ ca ] section and it did put SAN into the 
intermediate CA cert.


But I can't seem to get it into the root CA cert.

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant seem to get prompt no to work

[Jakob Bohm]

On 18/08/2017 00:09, Robert Moskowitz wrote:



On 08/17/2017 05:38 PM, Salz, Rich wrote:

declare -x organizationalUnitName=""
routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:151:minsize=1
You are setting an empty OU.  You should not set it and see if 
that works


organizationalUnitName = "."  puts a . in it.  So I have to figure out 
a way to drop that line from the config.


like if a field is not needed:

sed -i -e "s/^organizationalUnitName/#organizationalUnitName/w 
/dev/stdout" openssl-root.cnf



But this is not quite right.  I have to find the one that has ENV in 
it.  I DO have an example of one such to use...




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
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant get the subjectALtName inot the root cert

[Jeffrey Walton]

On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz  wrote:
> I guess I am making progress.  I am not getting SAN into the root cert.  my
> cnf has in it:
>
> [ req ]
> # Options for the `req` tool (`man req`).
> default_bits= 2048
> prompt  = no
> distinguished_name  = req_distinguished_name
> string_mask = utf8only
> req_extensions  = req_ext
>
> [ req_ext ]
> #subjectAltName = email:$ENV::adminemail
> #subjectAltName = email:ad...@htt-consult.com
> subjectAltName = IP:192.168.24.1
>
> I tried all three above alternatives for SAN.  No SAN in the root cert
> created with:
>
> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>   -new -x509 -days 7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem
>
> Thanks for any insight.
>
> This type of cnf worked for creating a CSR and with the copy option the SAN
> made it into the cert.

It looks a bit unusual for a Root CA.

As far as signing the CSR, you need

copy_extensions = copy

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Cant get the subjectALtName inot the root cert

[Robert Moskowitz]

I guess I am making progress.  I am not getting SAN into the root cert.  
my cnf has in it:


[ req ]
# Options for the `req` tool (`man req`).
default_bits= 2048
prompt  = no
distinguished_name  = req_distinguished_name
string_mask = utf8only
req_extensions  = req_ext

[ req_ext ]
#subjectAltName = email:$ENV::adminemail
#subjectAltName = email:ad...@htt-consult.com
subjectAltName = IP:192.168.24.1

I tried all three above alternatives for SAN.  No SAN in the root cert 
created with:


openssl req -config openssl-root.cnf -key private/ca.key.pem \
  -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem


Thanks for any insight.

This type of cnf worked for creating a CSR and with the copy option the 
SAN made it into the cert.


thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant seem to get prompt no to work

[Robert Moskowitz]

On 08/17/2017 05:38 PM, Salz, Rich wrote:

declare -x organizationalUnitName=""
routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:151:minsize=1

You are setting an empty OU.  You should not set it and see if that works
 

organizationalUnitName = "."  puts a . in it.  So I have to figure out a 
way to drop that line from the config.


like if a field is not needed:

sed -i -e "s/^organizationalUnitName/#organizationalUnitName/w 
/dev/stdout" openssl-root.cnf



But this is not quite right.  I have to find the one that has ENV in 
it.  I DO have an example of one such to use...



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant seem to get prompt no to work

[Robert Moskowitz]

ARGH!!!

On 08/17/2017 05:38 PM, Salz, Rich wrote:

declare -x organizationalUnitName=""
routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:151:minsize=1

You are setting an empty OU.  You should not set it and see if that works


So now I have to figure out how to handle an empty variable.  Need to 
see what will happen if the variable has a value of "." that the 
prompting takes for dropping that object...


The resultant cert does not have the SAN.  That is another thing I need 
to figure out.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant seem to get prompt no to work

[Salz, Rich via openssl-users]

> declare -x organizationalUnitName=""
> routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:151:minsize=1
   
You are setting an empty OU.  You should not set it and see if that works 


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant seem to get prompt no to work

[Robert Moskowitz]

On 08/17/2017 04:17 PM, Robert Moskowitz wrote:



On 08/17/2017 04:09 PM, Salz, Rich wrote:

Use the –batch flag to avoid all prompting


I commented out the prompt line and tried again:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
>   -new -x509 -days 7300 -sha256 -batch -extensions v3_ca -out 
certs/ca.cert.pem

Enter pass phrase for private/ca.key.pem:
error, no objects specified in config file
problems making Certificate Request

Is it not liking the use of ENV for the DN objects?  It worked for 
$ENV::dir...


export

...

declare -x adminemail="postmas...@htt-consult.com"
declare -x commonName="Root CA"
declare -x countryName="US"
declare -x dir="/root/ca"
declare -x localityName="Oak Park"
declare -x organizationName="HTT Consulting"
declare -x organizationalUnitName=""
declare -x stateOrProvinceName="MI"


[ req_distinguished_name ]
# See .
countryName = $ENV::countryName
stateOrProvinceName = $ENV::stateOrProvinceName
localityName= $ENV::localityName
0.organizationName  = $ENV::organizationName
organizationalUnitName  = $ENV::organizationalUnitName
commonName  = $ENV::commonName


When I put the prompt = no in the beginning of the [req] section ( saw 
that on one site), I get:


problems making Certificate Request
140134179792760:error:0D07A098:asn1 encoding 
routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:151:minsize=1


Is ENV not working in [req_distinguished_name]?


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant seem to get prompt no to work

[Robert Moskowitz]

On 08/17/2017 04:17 PM, Robert Moskowitz wrote:



On 08/17/2017 04:09 PM, Salz, Rich wrote:

Use the –batch flag to avoid all prompting


I commented out the prompt line and tried again:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
>   -new -x509 -days 7300 -sha256 -batch -extensions v3_ca -out 
certs/ca.cert.pem

Enter pass phrase for private/ca.key.pem:
error, no objects specified in config file
problems making Certificate Request

Is it not liking the use of ENV for the DN objects?  It worked for 
$ENV::dir...


export

...

declare -x adminemail="postmas...@htt-consult.com"
declare -x commonName="Root CA"
declare -x countryName="US"
declare -x dir="/root/ca"
declare -x localityName="Oak Park"
declare -x organizationName="HTT Consulting"
declare -x organizationalUnitName=""
declare -x stateOrProvinceName="MI"


[ req_distinguished_name ]
# See .
countryName = $ENV::countryName
stateOrProvinceName = $ENV::stateOrProvinceName
localityName= $ENV::localityName
0.organizationName  = $ENV::organizationName
organizationalUnitName  = $ENV::organizationalUnitName
commonName  = $ENV::commonName


I don't think it is the use of $ENV, as the following in cnf got the 
same failure:


countryName = US
stateOrProvinceName = MI
localityName= "Oak Park"
0.organizationName  = "HTT Consulting"
organizationalUnitName  =
commonName  = "Root CA"

I have removed the _default entries


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant seem to get prompt no to work

[Robert Moskowitz]

On 08/17/2017 04:09 PM, Salz, Rich wrote:

Use the –batch flag to avoid all prompting


I commented out the prompt line and tried again:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
>   -new -x509 -days 7300 -sha256 -batch -extensions v3_ca -out 
certs/ca.cert.pem

Enter pass phrase for private/ca.key.pem:
error, no objects specified in config file
problems making Certificate Request

Is it not liking the use of ENV for the DN objects?  It worked for 
$ENV::dir...


export

...

declare -x adminemail="postmas...@htt-consult.com"
declare -x commonName="Root CA"
declare -x countryName="US"
declare -x dir="/root/ca"
declare -x localityName="Oak Park"
declare -x organizationName="HTT Consulting"
declare -x organizationalUnitName=""
declare -x stateOrProvinceName="MI"


[ req_distinguished_name ]
# See .
countryName = $ENV::countryName
stateOrProvinceName = $ENV::stateOrProvinceName
localityName= $ENV::localityName
0.organizationName  = $ENV::organizationName
organizationalUnitName  = $ENV::organizationalUnitName
commonName  = $ENV::commonName


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant seem to get prompt no to work

[Salz, Rich via openssl-users]

Use the –batch flag to avoid all prompting

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant seem to get prompt no to work

[Robert Moskowitz]

On 08/17/2017 03:39 PM, Salz, Rich via openssl-users wrote:

In the CA section, you have to specify which fields you need/want in the DN.  
This is the “policy” identifier which points to a section that names the RDN’s 
you want/need.


I have that:

[ ca ]
# `man ca`
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
# dir   = /root/ca
certs = $ENV::dir/certs
crl_dir   = $ENV::dir/crl
new_certs_dir = $ENV::dir/newcerts
database  = $ENV::dir/index.txt
serial= $ENV::dir/serial
RANDFILE  = $ENV::dir/private/.rand

# The root key and root certificate.
private_key   = $ENV::dir/private/ca.key.pem
certificate   = $ENV::dir/certs/ca.cert.pem

# For certificate revocation lists.
crlnumber = $ENV::dir/crlnumber
crl   = $ENV::dir/crl/ca.crl.pem
crl_extensions= crl_ext
default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.
default_md= sha256

name_opt  = ca_default
cert_opt  = ca_default
default_days  = 375
preserve  = no
policy= policy_strict
prompt= no

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName = match
stateOrProvinceName = match
organizationName= match
organizationalUnitName  = optional
commonName  = optional

[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName = optional
stateOrProvinceName = optional
localityName= optional
organizationName= optional
organizationalUnitName  = optional
commonName  = optional

[ req ]
# Options for the `req` tool (`man req`).
default_bits= 2048
distinguished_name  = req_distinguished_name
string_mask = utf8only
req_extensions  = req_ext

# SHA-1 is deprecated, so use SHA-2 instead.
default_md  = sha256

# Extension to add when the -x509 option is used.
x509_extensions = v3_ca

[ req_distinguished_name ]
# See .
countryName = $ENV::countryName
stateOrProvinceName = $ENV::stateOrProvinceName
localityName= $ENV::localityName
0.organizationName  = $ENV::organizationName
organizationalUnitName  = $ENV::organizationalUnitName
commonName  = $ENV::commonName

[ req_ext ]
subjectAltName = email:$ENV::adminemail


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant seem to get prompt no to work

[Salz, Rich via openssl-users]

In the CA section, you have to specify which fields you need/want in the DN.  
This is the “policy” identifier which points to a section that names the RDN’s 
you want/need.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Cant seem to get prompt no to work

[Robert Moskowitz]

In the [ ca ] section I have:

prompt   = no

If I leave the = out I get an error, so I am assuming I got the format 
of this right.


Then I have

[ req ]
distinguished_name  = req_distinguished_name

[ req_distinguished_name ]
countryName = $ENV::countryName
stateOrProvinceName = $ENV::stateOrProvinceName

In a terminal window I run:

export countryName=US
export stateOrProvinceName=MI

then

openssl req -config openssl-root.cnf -key private/ca.key.pem \
  -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem



And I am still getting prompted for the DN fields:

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-
US []:

What did I miss?

thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

[Erwann Abalea via openssl-users]

> Le 17 août 2017 à 17:36, Jeffrey Walton  a écrit :
> 
> On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea
>  wrote:
>> 
>>> Le 17 août 2017 à 17:26, Jeffrey Walton  a écrit :
>>> 
> When you see a name like "example.com" in the CN, its usually a CA
> including a domain name and not a hostname.
 
 That's nonsense.
>>> 
>>> If a certificate is issued under CA/B policies, and CN=example.com but
>>> it _lacks_ SAN=example.com, then its a not a hostname and it should
>>> not be matched.
>> 
>> Such a certificate would be mis-issued and be revoked immediately. CN MUST 
>> be an FQDN (or a wild carded FQDN, or an IP address), and a copy of the 
>> value in CN MUST be present in the SAN extension.
> 
> Oh, you would have some fun watching how various user agents handle
> that scenario. For your first stop, check out how OpenSSL handles it.

I’m sure some user agents can have strange behaviors on such certificates. My 
remark took into consideration the CA/B policies. If such a certificate falls 
down under the CA/B policies (issued by a public CA, and a TLS server 
certificate), then it’s invalid.
Some browsers (maybe all?) ignore the CN if the SAN extension is present, even 
for private CAs.

Cordialement,
Erwann Abalea

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] More on cert serialnumbers

[Robert Moskowitz]

Erwann,

thank you for your response.

On 08/17/2017 11:29 AM, Erwann Abalea via openssl-users wrote:

Bonjour,


Le 17 août 2017 à 17:10, Robert Moskowitz  a écrit :



On 08/17/2017 10:50 AM, Salz, Rich via openssl-users wrote:

And RFC 5280, which is still the standard, says serial# must be <= 20 bytes.  
Which means, you want to make sure the high bit is off, else the DER encoding will 
make it 21 bytes.

So the new –rand_serial flag I am adding to the CA command will make call 
RAND_bytes to get 18 bytes.


On 8/17/17, 10:45 AM, "Salz, Rich via openssl-users" 
 wrote:

 https://cabforum.org/2016/07/08/ballot-164/

“Effective September 30, 2016, CAs SHALL generate Certificate serial numbers 
greater than zero (0) containing at least 64 bits of output from a CSPRNG.”

What does "64 bits of output from a CSPRNG" mean here?  A 4 octet serial number 
is OK?  Or 2^64 bit serial number represented in HEX (how long is that?)

That means that the serial number SHALL be at least 64 bits (8 octets) long, 
and at least 64 of the bits of the serial number come from a cryptographically 
strong pseudo random number generator.


ARGH!  Octets, not Hex!  :)



The BR are for public CAs, not private CAs; even if some of those requirements 
are considered « good practice » (the 64 bits out of a CSPRNG is such a req), 
they cannot be forced on private CAs.
And unless some or all of the browsers also apply these requirements to private 
CAs, you’re not forced to follow them all.


This may get interesting for some IoT situations.  The client certs 
would be used in protocols like CoAP (DTLS), but the server would be 
used by both the IoT clients and standard browsers.  If this were for a 
'smartcity' situation, the CA is probably public...



The 20 octets max comes from RFC5280, keep it.


Think we got that.


MD4/MD5/SHA1 forbidden, lets abandon obsolete crypto (non-collision resistant 
anymore).
The 64 bits from a CSPRNG is a tradeoff allowing the use of a 
non-collision-resistant hash function for slightly longer for transition 
periods, it’s nice if you can easily follow it, but browsers probably won’t 
enforce it.
The 2048bits minimum RSA key is really a good practice and shouldn’t be left 
over. Switch to ECDSA if your target permits it.


All my work on this project is ECDSA P-256 and I am chomping at the bit, 
so to speak, for Ed25519...



The CN deprecation and use of SAN:dNSName instead is a target of some browsers 
for private CAs; it may require more work for you, but there’s a benefit. CN 
has been populated with too much garbage (FQDN, domain, service name, IP 
address, person name, …), the SAN extension has nice baskets to put your eggs 
in (dNSName and iPAddress), and it works beautifully with NameConstraints.


I think I got this pretty much worked out now.


Cordialement,
Erwann Abalea


And thank you

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

[Jeffrey Walton]

On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea
 wrote:
>
>> Le 17 août 2017 à 17:26, Jeffrey Walton  a écrit :
>>
 When you see a name like "example.com" in the CN, its usually a CA
 including a domain name and not a hostname.
>>>
>>> That's nonsense.
>>
>> If a certificate is issued under CA/B policies, and CN=example.com but
>> it _lacks_ SAN=example.com, then its a not a hostname and it should
>> not be matched.
>
> Such a certificate would be mis-issued and be revoked immediately. CN MUST be 
> an FQDN (or a wild carded FQDN, or an IP address), and a copy of the value in 
> CN MUST be present in the SAN extension.

Oh, you would have some fun watching how various user agents handle
that scenario. For your first stop, check out how OpenSSL handles it.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

[Erwann Abalea via openssl-users]

> Le 17 août 2017 à 17:26, Jeffrey Walton  a écrit :
> 
>>> When you see a name like "example.com" in the CN, its usually a CA
>>> including a domain name and not a hostname.
>> 
>> That's nonsense.
> 
> If a certificate is issued under CA/B policies, and CN=example.com but
> it _lacks_ SAN=example.com, then its a not a hostname and it should
> not be matched.

Such a certificate would be mis-issued and be revoked immediately. CN MUST be 
an FQDN (or a wild carded FQDN, or an IP address), and a copy of the value in 
CN MUST be present in the SAN extension.

Cordialement,
Erwann Abalea

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] More on cert serialnumbers

[Erwann Abalea via openssl-users]

Bonjour,

> Le 17 août 2017 à 17:10, Robert Moskowitz  a écrit :
> 
> 
> 
> On 08/17/2017 10:50 AM, Salz, Rich via openssl-users wrote:
>> And RFC 5280, which is still the standard, says serial# must be <= 20 bytes. 
>>  Which means, you want to make sure the high bit is off, else the DER 
>> encoding will make it 21 bytes.
>> 
>> So the new –rand_serial flag I am adding to the CA command will make call 
>> RAND_bytes to get 18 bytes.
>> 
>> 
>> On 8/17/17, 10:45 AM, "Salz, Rich via openssl-users" 
>>  wrote:
>> 
>> https://cabforum.org/2016/07/08/ballot-164/
> 
> “Effective September 30, 2016, CAs SHALL generate Certificate serial numbers 
> greater than zero (0) containing at least 64 bits of output from a CSPRNG.”
> 
> What does "64 bits of output from a CSPRNG" mean here?  A 4 octet serial 
> number is OK?  Or 2^64 bit serial number represented in HEX (how long is 
> that?)

That means that the serial number SHALL be at least 64 bits (8 octets) long, 
and at least 64 of the bits of the serial number come from a cryptographically 
strong pseudo random number generator.

The BR are for public CAs, not private CAs; even if some of those requirements 
are considered « good practice » (the 64 bits out of a CSPRNG is such a req), 
they cannot be forced on private CAs.
And unless some or all of the browsers also apply these requirements to private 
CAs, you’re not forced to follow them all.

The 20 octets max comes from RFC5280, keep it.
MD4/MD5/SHA1 forbidden, lets abandon obsolete crypto (non-collision resistant 
anymore).
The 64 bits from a CSPRNG is a tradeoff allowing the use of a 
non-collision-resistant hash function for slightly longer for transition 
periods, it’s nice if you can easily follow it, but browsers probably won’t 
enforce it.
The 2048bits minimum RSA key is really a good practice and shouldn’t be left 
over. Switch to ECDSA if your target permits it.
The CN deprecation and use of SAN:dNSName instead is a target of some browsers 
for private CAs; it may require more work for you, but there’s a benefit. CN 
has been populated with too much garbage (FQDN, domain, service name, IP 
address, person name, …), the SAN extension has nice baskets to put your eggs 
in (dNSName and iPAddress), and it works beautifully with NameConstraints.

Cordialement,
Erwann Abalea

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

[Robert Moskowitz]

Viktor,

thanks for the reply.

On 08/17/2017 11:15 AM, Viktor Dukhovni wrote:

On Thu, Aug 17, 2017 at 12:56:20AM -0400, Jeffrey Walton wrote:


Remove commonName and emailAddress completely from the cnf file. They no
longer belong in any cert, root or intermediate CA certs, server or user
certs.

CommonName is supplied for viewing by tools like certificate viewers.
It should probably be a friendly name, like "Example Web Services".

RFC 5280 suggests an empty subject DN with all the desired names
in the the subject alt name extension.


When you see a name like "example.com" in the CN, its usually a CA
including a domain name and not a hostname.

That's nonsense.


For servers include something like in the cnf file:

subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost,
EMAIL:postmas...@example.com

Don't include an email address.

That is, don't incude unless the certificate is intended for S/MIME.


Or to provide an easy way to contact the server admin if there is a 
problem/question with the cert?  Even without S/MIME?





X.509 and PKIX certificates don't really have a proper field for email
addresses. That's why they get mashed into CommonName.

They sure do, that what's rfc822Name is for in the subject alt name
extenstion.  It supports S/MIME certificates.  There's even recent
work (soon to be an RFC) to internationalize this with SmtpUTF8Name...


That is what I thought, too.  Just not the full email format like:

Viktor Dukhovni 




Um, I can specify 'localhost' in this manner if I am on the server and
connecting in the browser with https://localhost ??

Yes.

You can, but it is not a good idea.  Since that "localhost" will
then work on every host that trusts the issuing CA.  The only way
to make this reasonably secure is to have a per-host issuing CA
that's only trusted on *that* host, and *that* CA can then issue
the "localhost" certificate.  All the hosts can additionally
trust other shared CAs.


So better to provide a self-signed cert if a server is going to be 
accessed from a browser on the server via https://localhost





I am looking at how to build the above line using ENV variables. It is more
a matter of how I do it than can I do it...

The tricky bit is creating a variable number of SAN elements, I don't
know how to do that with just environment variables.  Sometimes building
a config file on the fly is the way to go.


The simplest that I have come up with is:

export SAN = "DNS:example.com, DNS:www.example.com, 
EMAIL:postmas...@example.com"


and in the cnf

subjectAltName = $SAN

I think.   I am not yet up to testing this

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

[Jeffrey Walton]

>> When you see a name like "example.com" in the CN, its usually a CA
>> including a domain name and not a hostname.
>
> That's nonsense.

If a certificate is issued under CA/B policies, and CN=example.com but
it _lacks_ SAN=example.com, then its a not a hostname and it should
not be matched.

I'm aware of OpenSSL's behavior in the matter. But OpenSSL does not
understand issuing policies so its easy to confuse.

Forgive me if OpenSSL is now imbued with knowledge of issuing policies
and how matching should occur outside of the RFCs.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] More on cert serialnumbers

[Robert Moskowitz]

On 08/17/2017 10:49 AM, Karl Denninger wrote:



On 8/17/2017 09:40, Robert Moskowitz wrote:

I have been researching serial number in cert based on Jakob's comment:

"- Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as 
standalone
 numbers and as DER-encoded numbers.  Note that this is not the 
default in

 the openssl ca program.

- Serial numbers contain cryptographically strong random bits, 
currently at
 least 64 random bits, though it is best if the entire serial number 
looks
 random from the outside.  This is not implemented by the openssl ca 
program."


And this is supposedly from the CA/B BF?

Though Erwann responded:

"There’s no such requirement. It MUST be at most 20 octets long"

I see how for all certs other than the root (get to that later), I 
can control this with:


openssl rand -hex 20 > serial

then use 'openssl ca ...'

But from Kyle's comment, the first bit must be ZERO.
So since the 20 octets is a maximum and not a requirement use -hex 19 
instead, and if this results in DER placing a leading 0x00 byte you're 
still ok.  This also complies with the ballot that Rich mentioned 
since you have more entropy than required.


At least I think that meets the requirements


And 19 is more than 18!  And the first time I tried this I got:

a2b7499f19b3b7b4a54ccd2036d59a4a906756

And the 2nd time I tried with 20:

f7f01d018605411c8788a82e465d7991d574b08f

So that first bit can really be a problem.  Probably about 1/2 the time!  :)

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

[Viktor Dukhovni]

On Thu, Aug 17, 2017 at 12:56:20AM -0400, Jeffrey Walton wrote:

> > Remove commonName and emailAddress completely from the cnf file. They no
> > longer belong in any cert, root or intermediate CA certs, server or user
> > certs.
> 
> CommonName is supplied for viewing by tools like certificate viewers.
> It should probably be a friendly name, like "Example Web Services".

RFC 5280 suggests an empty subject DN with all the desired names
in the the subject alt name extension.

> When you see a name like "example.com" in the CN, its usually a CA
> including a domain name and not a hostname.

That's nonsense.

> > For servers include something like in the cnf file:
> >
> > subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost,
> > EMAIL:postmas...@example.com
> 
> Don't include an email address.

That is, don't incude unless the certificate is intended for S/MIME.

> X.509 and PKIX certificates don't really have a proper field for email
> addresses. That's why they get mashed into CommonName.

They sure do, that what's rfc822Name is for in the subject alt name
extenstion.  It supports S/MIME certificates.  There's even recent
work (soon to be an RFC) to internationalize this with SmtpUTF8Name...

> > Um, I can specify 'localhost' in this manner if I am on the server and
> > connecting in the browser with https://localhost ??
> 
> Yes.

You can, but it is not a good idea.  Since that "localhost" will
then work on every host that trusts the issuing CA.  The only way
to make this reasonably secure is to have a per-host issuing CA
that's only trusted on *that* host, and *that* CA can then issue
the "localhost" certificate.  All the hosts can additionally
trust other shared CAs.

> > I am looking at how to build the above line using ENV variables. It is more
> > a matter of how I do it than can I do it...

The tricky bit is creating a variable number of SAN elements, I don't
know how to do that with just environment variables.  Sometimes building
a config file on the fly is the way to go.

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] More on cert serialnumbers

[Robert Moskowitz]

On 08/17/2017 10:50 AM, Salz, Rich via openssl-users wrote:

And RFC 5280, which is still the standard, says serial# must be <= 20 bytes.  
Which means, you want to make sure the high bit is off, else the DER encoding will 
make it 21 bytes.

So the new –rand_serial flag I am adding to the CA command will make call 
RAND_bytes to get 18 bytes.


On 8/17/17, 10:45 AM, "Salz, Rich via openssl-users" 
 wrote:

 https://cabforum.org/2016/07/08/ballot-164/


“Effective September 30, 2016, CAs SHALL generate Certificate serial 
numbers greater than zero (0) containing at least 64 bits of output from 
a CSPRNG.”


What does "64 bits of output from a CSPRNG" mean here?  A 4 octet serial 
number is OK?  Or 2^64 bit serial number represented in HEX (how long is 
that?)


For now I will use:

openssl rand -hex 18 > serial

My reading on 'openssl rand' SEEMS to indicate it is cryptographically 
strong (provided you have entropy.  See:  cat 
/proc/sys/kernel/random/entropy_avail


For constrained IoT, I would like to use the smallest possible. Thus the 
clarifying the 64bit question above.


thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] More on cert serialnumbers

[Karl Denninger]

On 8/17/2017 09:40, Robert Moskowitz wrote:
> I have been researching serial number in cert based on Jakob's comment:
>
> "- Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as
> standalone
>  numbers and as DER-encoded numbers.  Note that this is not the
> default in
>  the openssl ca program.
>
> - Serial numbers contain cryptographically strong random bits,
> currently at
>  least 64 random bits, though it is best if the entire serial number
> looks
>  random from the outside.  This is not implemented by the openssl ca
> program."
>
> And this is supposedly from the CA/B BF?
>
> Though Erwann responded:
>
> "There’s no such requirement. It MUST be at most 20 octets long"
>
> I see how for all certs other than the root (get to that later), I can
> control this with:
>
> openssl rand -hex 20 > serial
>
> then use 'openssl ca ...'
>
> But from Kyle's comment, the first bit must be ZERO.
So since the 20 octets is a maximum and not a requirement use -hex 19
instead, and if this results in DER placing a leading 0x00 byte you're
still ok.  This also complies with the ballot that Rich mentioned since
you have more entropy than required.

At least I think that meets the requirements

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] More on cert serialnumbers

[Salz, Rich via openssl-users]

And RFC 5280, which is still the standard, says serial# must be <= 20 bytes.  
Which means, you want to make sure the high bit is off, else the DER encoding 
will make it 21 bytes.

So the new –rand_serial flag I am adding to the CA command will make call 
RAND_bytes to get 18 bytes.


On 8/17/17, 10:45 AM, "Salz, Rich via openssl-users" 
 wrote:

https://cabforum.org/2016/07/08/ballot-164/


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] More on cert serialnumbers

[Salz, Rich via openssl-users]

https://cabforum.org/2016/07/08/ballot-164/


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] More on cert serialnumbers

[Robert Moskowitz]

I have been researching serial number in cert based on Jakob's comment:

"- Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as 
standalone

 numbers and as DER-encoded numbers.  Note that this is not the default in
 the openssl ca program.

- Serial numbers contain cryptographically strong random bits, currently at
 least 64 random bits, though it is best if the entire serial number looks
 random from the outside.  This is not implemented by the openssl ca 
program."


And this is supposedly from the CA/B BF?

Though Erwann responded:

"There’s no such requirement. It MUST be at most 20 octets long"

I see how for all certs other than the root (get to that later), I can 
control this with:


openssl rand -hex 20 > serial

then use 'openssl ca ...'

But from Kyle's comment, the first bit must be ZERO.

"I tend not to re-use keys, so I've found that putting 20 bytes (while 
clearing the high bit) of a digest of the SubjectPublicKeyInfo as the 
serial number works in that circumstance.  [if you leave the high bit 
set, then DER mandates that it be encoded with a leading 0x00 byte, 
which makes it 21 bytes... which can cause problems with things built 
for PKIX.]"


Will that be the case with the above 'openssl rand', or is there some 
other step needed to zero out the first bit.


And is the openssl rand function 'safe' to use?  Is it cryptographically 
strong?


As for the root cert created with 'openssl req ... -new -x509', it seems 
that a random 8 octet serial number is provided.  Is there a way to 
boost that to 20 octects?  Does it matter per Erwann's comment above?


Actually, I am trying to keep certs small, and the CAs I picture are not 
for millions of certs  Smaller serial number size would be the preferred 
situation...


thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] keyusage digitalSignature in CA certs

[Robert Moskowitz]

Thank you for your response.

I am basically skipping 20 years of PKI development and trying to get to 
current best practices...


On 08/17/2017 09:50 AM, Erwann Abalea via openssl-users wrote:

Bonjour,


Le 17 août 2017 à 15:20, Robert Moskowitz  a écrit :

Should digitalSignature be included in keyusage in CA certs?

It depends on what you plan to do with the corresponding private key.
If you want this private key to sign messages other than certificates and CRLs 
(such as OCSP responses), then yes.


Got it and your follow-on points.

Again, thank you.




https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html

Includes it.

https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898

Does not include it.

It seems to make a root or intermediate CA be able to have more purposes than 
it should?  e.g.

SSL client : Yes
SSL server : Yes
S/MIME signing : Yes

This is the result of an analysis of the keyUsage *and* the extendedKeyUsage 
extensions (and maybe obsolete Netscape proprietary ones).


So which is the right for a CA's key usage?

That really depends on what you want it to be valid for.

keyUsage=keyCertSign is fine for certificate signing
keyUsage=cRLSign is fine for CRL signing
keyUsage=digitalSignature is fine for OCSP signing

The other bits are not that common for a CA.

You can achieve the capabilities with different certificates.

For example, a keyCertSign-only CA cert can self-issue a cRLSign certificate in 
order to produce CRLs and a digitalSignature certificate to sign OCSP 
responses, or an issuing CA can issue different certificates for the same CA 
(they all have the same Subject, which is different from the issuing’s Subject) 
but for different purposes (and thus different keyUsage bits).

Cordialement,
Erwann Abalea



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] keyusage digitalSignature in CA certs

[Erwann Abalea via openssl-users]

Bonjour,

> Le 17 août 2017 à 15:20, Robert Moskowitz  a écrit :
> 
> Should digitalSignature be included in keyusage in CA certs?

It depends on what you plan to do with the corresponding private key.
If you want this private key to sign messages other than certificates and CRLs 
(such as OCSP responses), then yes.

> 
> https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html
> 
> Includes it.
> 
> https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898
> 
> Does not include it.
> 
> It seems to make a root or intermediate CA be able to have more purposes than 
> it should?  e.g.
> 
> SSL client : Yes
> SSL server : Yes
> S/MIME signing : Yes

This is the result of an analysis of the keyUsage *and* the extendedKeyUsage 
extensions (and maybe obsolete Netscape proprietary ones).

> So which is the right for a CA's key usage?

That really depends on what you want it to be valid for.

keyUsage=keyCertSign is fine for certificate signing
keyUsage=cRLSign is fine for CRL signing
keyUsage=digitalSignature is fine for OCSP signing

The other bits are not that common for a CA.

You can achieve the capabilities with different certificates.

For example, a keyCertSign-only CA cert can self-issue a cRLSign certificate in 
order to produce CRLs and a digitalSignature certificate to sign OCSP 
responses, or an issuing CA can issue different certificates for the same CA 
(they all have the same Subject, which is different from the issuing’s Subject) 
but for different purposes (and thus different keyUsage bits).

Cordialement,
Erwann Abalea

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] keyusage digitalSignature in CA certs

[Blumenthal, Uri - 0553 - MITLL]

AFAIK it must.

Regards,
Uri

Sent from my iPhone

> On Aug 17, 2017, at 09:21, Robert Moskowitz  wrote:
> 
> Should digitalSignature be included in keyusage in CA certs?
> 
> 
> https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html
> 
> Includes it.
> 
> https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898
> 
> Does not include it.
> 
> It seems to make a root or intermediate CA be able to have more purposes than 
> it should?  e.g.
> 
> SSL client : Yes
> SSL server : Yes
> S/MIME signing : Yes
> 
> So which is the right for a CA's key usage?
> 
> thanks
> 
> Bob
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] keyusage digitalSignature in CA certs

[Robert Moskowitz]

Should digitalSignature be included in keyusage in CA certs?


https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html

Includes it.

https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898

Does not include it.

It seems to make a root or intermediate CA be able to have more purposes 
than it should?  e.g.


SSL client : Yes
SSL server : Yes
S/MIME signing : Yes

So which is the right for a CA's key usage?

thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

[Robert Moskowitz]

On 08/17/2017 12:56 AM, Jeffrey Walton wrote:

On Thu, Aug 17, 2017 at 12:28 AM, Robert Moskowitz  wrote:

I have skimmed through a few RFCs following today's postings and a few web
sites.  It would seem to me that I should:

Remove commonName and emailAddress completely from the cnf file. They no
longer belong in any cert, root or intermediate CA certs, server or user
certs.

CommonName is supplied for viewing by tools like certificate viewers.
It should probably be a friendly name, like "Example Web Services".

Don't include hostnames in the CN. If you list it in the CN, then it
must be listed in the SAN, too. You must list it twice.

When you see a name like "example.com" in the CN, its usually a CA
including a domain name and not a hostname. It confusing for users and
user agents. I've seen user agents match a hostname based on the
domain name.

On the backend, there's usually a redirect for the domain example.com
to send user agents to a host like www.example.com. It happens up at
layer 7, not at layer 4.


So commonName does make some sense, for those that want to verbosely 
define the name.  But not for fqdns.





For servers include something like in the cnf file:

subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost,
EMAIL:postmas...@example.com

Don't include an email address.

X.509 and PKIX certificates don't really have a proper field for email
addresses. That's why they get mashed into CommonName.


I have looked through a lot of rfcs and do not see this.  If you mean a 
full email address like


Jeffrey Walton 

I see that.  And it explains the mashing you see when you display the 
subjectName:


CN=www.htt-consult.com/emailAddress=ad...@htt-consult.com

Yes, I now know I should not have put the fqdn in there

But

subjectAltName  = email:hostmas...@example.org

Clearly is a valid rfc822name and is a proper email address for server 
contact and even user certs.


So why do you recommend NOT putting email address in SAN when so many 
others DO recommend it.  Is there some clear directive from some forum 
(CA/B BR)?  And it seems this is how Microsoft encodes email addresses 
(but not user names, see below).





(That is all suppose to be on a single line in case your mail viewer wraps
it).

Um, I can specify 'localhost' in this manner if I am on the server and
connecting in the browser with https://localhost ??

Yes.

You can also put IP addresses there. The RFC's mostly allow it. The
CA/Browser Forum Baseline Requirements (CA/B BR) forbids it, but its
not clear (to me) what current browser behavior is.

For completeness, non-browser user agents, like wget and openssl,
follow the RFC standards and issuing policies. Browsers follow the
CA/B BR. That's why you often see browsers reject something accepted
by other user agents.

You might also be interested in
https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898
and 
https://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl.
They questions and answers reference about 6 different standards.


And for clients:

subjectAltName = EMAIL:u...@example.com

I am looking at how to build the above line using ENV variables. It is more
a matter of how I do it than can I do it...

This is a whole 'nother can of worms. Also see
https://security.stackexchange.com/questions/62746/how-to-encode-a-username-in-pkix-certificate.


Fun read.  Since I am not striving for MS coordination, and so far I 
have not dove into LDAP issues, I would go for DN/UID added to the user 
cnf file.


thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users