Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Ben Humpert]

Fun Fact: (For me) Gmail often marks completely legit emails from
mailing lists as spam and you manually have to mark them as "no spam".
The fun comes in when you notice that actual spam is not marked as
such at all.

Looks like strong encryption is much easier to develop than a decent
spam filter.

The main problem I guess is that neither Google nor any other major
email provider actually block other email providers who do not offer
SPF, SMTP2SMTP encryption or whatever else. If they would do so, we
would have solved most major (email) problems within a week or at
least a month. Either by forcing those to offer these security
features or by "killing" these providers indirectly.

2016-04-02 17:41 GMT+02:00 Jeffrey Walton :
> On Sat, Apr 2, 2016 at 11:24 AM, Salz, Rich  wrote:
>>
>>> why is junk like this not being caught?
>>
>> Almost all of it is.  Nothing is perfect.  Thanks for your understanding and 
>> patience.
>
> I was looking at some of it landing in my Inbox. Its all from Gmail
> users. The headers are Gmail headers submitted via the web. The DKIM
> signatures are OK. There are no headers to indicate its been
> forwarded. The {from|return|reply to} address does not appear to
> forged. Here's an example header from another Gmail user who contacted
> me: http://pastebin.com/hRAtRt7S.
>
> I've also had a couple of people contact me asking me to stop spamming
> them. I looked at two of those headers, and it clearly appears to be
> coming from me though I did not send it (and no evidence in my
> Outbox).
>
> I'm thinking there's a vulnerability in the Gmail or Google servers we
> have not heard about.
>
> Jeff
> --
> 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] Properly manage CA-signed certificates that have expired

[Ben Humpert]

I see. Thank you very much Jakob and Jeffrey!
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Properly manage CA-signed certificates that have expired

[Ben Humpert]

2016-03-31 18:09 GMT+02:00 Jakob Bohm :
> On 31/03/2016 17:16, warron.french wrote:
> 3.  Then create new server certificates for the 2 servers again.
>
> Yep, and give the new ones a slightly different "full"
> distinguished name (important for CRL and "ca" database).
> My approach is to include the year-month as an extra OU e.g.
>
>   CN=foo.example.private,OU=isonetwork,OU=2016-03,O=YourCompany
> Inc,L=YourTown,C=XX

Why is this that important? Isn't the serial and/or keyid/hash enough
to differentiate between both certs? Or is it just another "layer of
security" for some not that correctly working clients out there?

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

Re: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16)

[Ben Humpert]

2015-12-13 22:57 GMT+01:00 Salz, Rich :
>
>> And we don't know on which client OP will have to use that pem file, thus
>> give advise that works on all clients, not just OpenSSL or GnuTLS or 
>> whatever.
>
> It is quite reasonable to give openssl-specific answers on the openssl-users 
> mailing list, isn’t it?

All given answers are openssl-specific (OP uses OpenSSL to CREATE the
bundle but likely not to READ / USE the created bundle). You are
intelligent enough to understand the difference, aren't you?

The problem with Viktor Dukhovni is that he acts like THE AUTHORITY;
saying all other given answers are wrong (actually none is).
Additionally his solution is complicated and only works with OpenSSL.

Since Windows, Mac, GnuTLS, OpenSSL, Android, iPhone, etc. understand
a pkcs7 container and since nobody knows on what clients the bundle
will be used Walter Hs answer is the best solution.

You know encryption but obviously not that there is a world beyond
OpenSSL. And as I already wrote: If you want to use the bundle on
Windows you CANNOT simply concatenate all the certs into one certs.pem
because Windows (and various other Operating Systems) does not
understand that format.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16)

[Ben Humpert]

2015-12-13 3:53 GMT+01:00 Viktor Dukhovni :
>
> In other words, you can concatenate all the trusted root CA
> certs into the "cert.pem" file in that directory, but this
> has a performance cost, as all the certificates are loaded
> into memory and parse even though most go unused.  Alternatively,


The problem with concatenating certs into one file is that at least
Windows does not understand that format and just reads the first
certificate but ignores all following.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16)

[Ben Humpert]

2015-12-13 20:27 GMT+01:00 Viktor Dukhovni :
>
> This is both wrong and irrelevant.  The OP should proceed as instructed.
> OpenSSL's CAfile feature reads multiple certificates from a single file.

Exactly that is the point. Only "linux based" tools will be able to
read such a pem file. Windows certificate tools are not able to do so.
And we don't know on which client OP will have to use that pem file,
thus give advise that works on all clients, not just OpenSSL or GnuTLS
or whatever.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16)

[Ben Humpert]

Hi,

so if I understand you correctly you want to create one file that
contains more than one CA certificate and can be installed onto
Windows, Mac, etc.? You only can do that if you create a p12 file and
that must contain a leaf certificate and its private key.

openssl pkcs12 -export -in out/X.crt -inkey out/X.key -chain -out out/X.p12

You can check the openssl pkcs12 help for more arguments.

Best regards,

Ben

2015-12-12 22:23 GMT+01:00 Dominik Mahrer (Teddy) :
> Hi everyone
>
> My question is:
> How can I set up a bundle of commercial root CA certificates?
> Exactly this the same question I found as FAQ # 16 (User). But as answer
> there is only explained that openssl will not serve a bundle. But it is not
> explained how to set up a bundle - but exactly this I would like to know.
>
> Thanks in advice
> Teddy
>
> --
> Teddy Engineering GmbH http://www.teddy.ch/
> Lettenmattstrasse 5mailto:te...@teddy.ch
> 8903 Birmensdorf ZH+41 32 511 07 48
>
>
>
> ___
> 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] sign sub CA issue

[Ben Humpert]

Tell the person who created the CSR that the value of the
stateOrProvinceName field has to be HK. If that is not possible
because the subCA is in a different country you can change your
openssl.cnf to allow different values in that field so instead of
stateOrProvinceName = match you have to use at least
stateOrProvinceName = supplied

2015-12-11 15:18 GMT+01:00 Mohammad Jebran :
> Please can I have some advise on this query.
>
> Regards,
> Jebran.
>
> On Tue, Dec 8, 2015 at 11:18 AM, Mohammad Jebran  wrote:
>>
>> I have to sign a sub-CA through my current root CA using openSSLeverything
>> I have configured as per instructions but still getting an error that
>> "stateorProvanceName field needed to be the same" As mentioned below.
>>
>>
>>
>>
>>
>> root@machine:~/ImportantCACerts/intermediate# openssl ca
>> -configopenssl.cnf -extensions v3_intermediate_ca -days 3650 -notext -md
>> sha256 -in csr/subca2.csr -out certs/subca2.crt
>>
>> Using configuration from openssl.cnf
>>
>> Check that the request matches the signature
>>
>> Signature ok
>>
>> The stateOrProvinceName field needed to be the same in the
>>
>> CA certificate (HK) and the request (HK)
>>
>>
>>
>>
>>
>> Thanks & Regards,
>> Jebran.
>
>
>
> ___
> 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] How do I configure my Certification Authority to pay attention to Subject Alternate Names

[Ben Humpert]

That guide is a little bit old and not very accurate. I setup my PKI
using the OpenSSL Cookbook recommended to me by Rich Salz. This free
guide / documentation is here:
https://www.feistyduck.com/books/openssl-cookbook/ (Click "Free: Read
Now" below the cover image). I also used various other sources to
improve and adapt the configuration files and command lines.

First of all the configuration files:
openssl.cnf - 
https://drive.google.com/file/d/0B8gf20AKtya0VEhGYm82YUhraDQ/view?usp=sharing
reqs/client_sample.cnf -
https://drive.google.com/file/d/0B8gf20AKtya0QWNIbjY0WUtLVEk/view?usp=sharing
reqs/server_sample.cnf -
https://drive.google.com/file/d/0B8gf20AKtya0Y2tLOU1FaGFnUE0/view?usp=sharing


The first initialization of the CA database is done by the following commands:

cd /etc/ssl/
mkdir -p ./ca/db ./ca/private ./ca/certs ./ca/crl ./ca/out
chmod 700 ./ca/private
cp /dev/null ./ca/db/SampleCA.db
cp /dev/null ./ca/db/SampleCA.db.attr
openssl rand -hex 16  > ./ca/db/SampleCA.crt.srl
echo 1001 > ./ca/db/SampleCA.crl.srl
cd /etc/ssl/ca/


To get a self-signed cert/key for the CA itself:

openssl req -new -out SampleCA.csr
openssl ca -selfsign -in SampleCA.csr -out SampleCA.crt -extensions
RootCA_x509_ext -notext -startdate 15010100Z -enddate
191231235959Z


To get a cert/key for a server:

openssl req -new -config reqs/server_sample.cnf -out out/XXX.csr
-keyout out/XXX.key
openssl ca -in out/XXX.csr -out out/XXX.crt -extensions
Server_x509_ext -policy Machine_policy -notext -startdate
15010100Z -enddate 191231235959Z


To get a ECC cert/key for a server:

openssl ecparam -genkey -name secp256r1 | openssl ec -out out/XXX.key -aes128
openssl req -new -config reqs/server_sample.cnf -out out/XXX.csr -key
out/XXX.key
openssl ca -in out/XXX.csr -out out/XXX.crt -extensions
Server_x509_ext -policy Machine_policy -notext -startdate
15010100Z -enddate 191231235959Z


There are two methods of creating certificates for clients. You can
either issue for a human being or a machine. My PKI is not for a
company but a flat sharing, thus I have plenty of different device
owners, thus I issue certificates for human beings. That way every
device gets its unique certificate with information about the device
owner. The exact differences can be seen by comparing the
"distinguished_name" section in server_sample.cnf and
client_sample.cnf.

If you want to issue for machines instead you have to modify the
following commands a bit as well as the client_sample.cnf but you can
use the information for servers above to get what you need :)

To get a cert/key for a client:

openssl req -new -config reqs/client_sample.cnf -out out/XXX.csr
-keyout out/XXX.key
openssl ca -in out/XXX.csr -out out/XXX.crt -extensions
Client_x509_ext -policy User_policy -notext -startdate 15010100Z
-enddate 151231235959Z

2015-11-04 5:31 GMT+01:00 Walter H. :
> On 03.11.2015 18:45, John Lewis wrote:
>
> On 11/03/2015 12:04 PM, Walter H. wrote:
>
> On 03.11.2015 14:46, John Lewis wrote:
>
> I created a local certification authority  using this tutorial
> https://www.debian-administration.org/article/284/Creating_and_Using_a_self_signed__SSL_Certificates_in_debian
> and made a certification request using this tutorial and I use this
> tutorial to learn how to make a request with a Subject Alternate Name.
>
> I actually did manage to get lucky just now and I hypothesize that
> running a command like this 'openssl ca -in ldap01.req -out
> certs/new/ldap04.pem -extensions v3_req -config ./openssl.cnf' as
> opposed to running a command like this 'openssl ca -in ldap01.req -out
> certs/new/ldap04.pem  -config ./openssl.cnf' got my CA to create a cert
> with subject alternate names. How do I add '-extensions v3_req' to my ca
> configuration and have it be not be ignored?
>
>
> add the following parameter(s):
>
> -extensions sslcertext -extfile file
> this file is similar to the following
>
> [ sslcertext ]
> basicConstraints = CA:false
> keyUsage = critical, digitalSignature, keyEncipherment
> subjectKeyIdentifier = hash
> authorityKeyIdentifier = keyid:always, issuer:always
> authorityInfoAccess = OCSP;URI:#OCSP-URL#/, caIssuers;URI:#DER-CACERT-URL#
>
> issuerAltName = issuer:copy
> subjectAltName = #SUBJECTALTNAME#
>
> extendedKeyUsage = serverAuth, msSGC, nsSGC
>
> certificatePolicies = ia5org, @policy_section
> crlDistributionPoints = URI:#CRL-URL#
>
> [ policy_section ]
> policyIdentifier = #POLICYID#
> CPS.1 = #CPS-URL#
>
>
> Do I replace my current [v3_req] section with the contents of [sslcertext]
>
> No, you add this part, because v3_req is used for the certificate request
> ...
>
> and I have forgotten to mention, that #...# must be replaced with the right
> values;
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
___
openssl-users mailing list
To unsubscribe: 

Re: [openssl-users] How do I configure my Certification Authority to pay attention to Subject Alternate Names

[Ben Humpert]

Oh crappy Gmail stop creating broken links ...

openssl.cnf is at
https://drive.google.com/file/d/0B8gf20AKtya0VEhGYm82YUhraDQ/view?usp=sharing


reqs/client_sample.cnf is at
https://drive.google.com/file/d/0B8gf20AKtya0QWNIbjY0WUtLVEk/view?usp=sharing


reqs/server_sample.cnf is at
https://drive.google.com/file/d/0B8gf20AKtya0Y2tLOU1FaGFnUE0/view?usp=sharing

2015-11-04 16:06 GMT+01:00 Ben Humpert <b...@an3k.de>:
> That guide is a little bit old and not very accurate. I setup my PKI
> using the OpenSSL Cookbook recommended to me by Rich Salz. This free
> guide / documentation is here:
> https://www.feistyduck.com/books/openssl-cookbook/ (Click "Free: Read
> Now" below the cover image). I also used various other sources to
> improve and adapt the configuration files and command lines.
>
> First of all the configuration files:
> openssl.cnf - 
> https://drive.google.com/file/d/0B8gf20AKtya0VEhGYm82YUhraDQ/view?usp=sharing
> reqs/client_sample.cnf -
> https://drive.google.com/file/d/0B8gf20AKtya0QWNIbjY0WUtLVEk/view?usp=sharing
> reqs/server_sample.cnf -
> https://drive.google.com/file/d/0B8gf20AKtya0Y2tLOU1FaGFnUE0/view?usp=sharing
>
>
> The first initialization of the CA database is done by the following commands:
>
> cd /etc/ssl/
> mkdir -p ./ca/db ./ca/private ./ca/certs ./ca/crl ./ca/out
> chmod 700 ./ca/private
> cp /dev/null ./ca/db/SampleCA.db
> cp /dev/null ./ca/db/SampleCA.db.attr
> openssl rand -hex 16  > ./ca/db/SampleCA.crt.srl
> echo 1001 > ./ca/db/SampleCA.crl.srl
> cd /etc/ssl/ca/
>
>
> To get a self-signed cert/key for the CA itself:
>
> openssl req -new -out SampleCA.csr
> openssl ca -selfsign -in SampleCA.csr -out SampleCA.crt -extensions
> RootCA_x509_ext -notext -startdate 15010100Z -enddate
> 191231235959Z
>
>
> To get a cert/key for a server:
>
> openssl req -new -config reqs/server_sample.cnf -out out/XXX.csr
> -keyout out/XXX.key
> openssl ca -in out/XXX.csr -out out/XXX.crt -extensions
> Server_x509_ext -policy Machine_policy -notext -startdate
> 15010100Z -enddate 191231235959Z
>
>
> To get a ECC cert/key for a server:
>
> openssl ecparam -genkey -name secp256r1 | openssl ec -out out/XXX.key -aes128
> openssl req -new -config reqs/server_sample.cnf -out out/XXX.csr -key
> out/XXX.key
> openssl ca -in out/XXX.csr -out out/XXX.crt -extensions
> Server_x509_ext -policy Machine_policy -notext -startdate
> 15010100Z -enddate 191231235959Z
>
>
> There are two methods of creating certificates for clients. You can
> either issue for a human being or a machine. My PKI is not for a
> company but a flat sharing, thus I have plenty of different device
> owners, thus I issue certificates for human beings. That way every
> device gets its unique certificate with information about the device
> owner. The exact differences can be seen by comparing the
> "distinguished_name" section in server_sample.cnf and
> client_sample.cnf.
>
> If you want to issue for machines instead you have to modify the
> following commands a bit as well as the client_sample.cnf but you can
> use the information for servers above to get what you need :)
>
> To get a cert/key for a client:
>
> openssl req -new -config reqs/client_sample.cnf -out out/XXX.csr
> -keyout out/XXX.key
> openssl ca -in out/XXX.csr -out out/XXX.crt -extensions
> Client_x509_ext -policy User_policy -notext -startdate 15010100Z
> -enddate 151231235959Z
>
> 2015-11-04 5:31 GMT+01:00 Walter H. <walte...@mathemainzel.info>:
>> On 03.11.2015 18:45, John Lewis wrote:
>>
>> On 11/03/2015 12:04 PM, Walter H. wrote:
>>
>> On 03.11.2015 14:46, John Lewis wrote:
>>
>> I created a local certification authority  using this tutorial
>> https://www.debian-administration.org/article/284/Creating_and_Using_a_self_signed__SSL_Certificates_in_debian
>> and made a certification request using this tutorial and I use this
>> tutorial to learn how to make a request with a Subject Alternate Name.
>>
>> I actually did manage to get lucky just now and I hypothesize that
>> running a command like this 'openssl ca -in ldap01.req -out
>> certs/new/ldap04.pem -extensions v3_req -config ./openssl.cnf' as
>> opposed to running a command like this 'openssl ca -in ldap01.req -out
>> certs/new/ldap04.pem  -config ./openssl.cnf' got my CA to create a cert
>> with subject alternate names. How do I add '-extensions v3_req' to my ca
>> configuration and have it be not be ignored?
>>
>>
>> add the following parameter(s):
>>
>> -extensions sslcertext -extfile file
>> this file is similar to the following
>>
>> [ sslcertext ]
>> basicConstraints 

Re: [openssl-users] Certificate serialnumber?

[Ben Humpert]

Take a look in your openssl.cnf and you should see the option serial
with a path / file specified. The serial number is taken from that
file. If the file doesn't exists or is empty when the very first
certificate is created then 01 is used as a serial for it.

Rich Salz recommended me this SSL Cookbook
https://www.feistyduck.com/books/openssl-cookbook/ by Ivan Ristić and
based on that you should initiate the database and serial files before
you create certificates to avoid problems that can occour after month
/ years.

I use

cd /etc/ssl/
mkdir -p ./ca/db ./ca/private ./ca/certs ./ca/crl ./ca/out ./ca/reqs
chmod 700 ./ca/private
cp /dev/null ./ca/db/an3kRootCA.db
cp /dev/null ./ca/db/an3kRootCA.db.attr
openssl rand -hex 16   ./ca/db/an3kRootCA.crt.srl
echo 1001  ./ca/db/an3kRootCA.crl.srl
cd /etc/ssl/ca/

to create the whole environment and initiate the database and serial
files. This is based on the SSL Cookbook information. If you want to
read it for yourself please open
https://www.feistyduck.com/library/openssl-cookbook/online/ch-openssl.html
begin with paragraph Creating a Private Certification Authority
(F3).

2015-07-05 12:48 GMT+02:00 Walter H. walte...@mathemainzel.info:
 Hello,

 I'm using openssl command-line in a Linux-Box (CentOS 6.x with squid) like
 this:

 I havn't defined anything - everything is set default from the linux
 distribution
 openssl req -new -newkey rsa:2048 -subj '/CN=Squid SSL-Bump CA/C=/O=/OU=/'
 -sha256 -days 365 -nodes -x509 -keyout ./squidCA.pem -out ./squidCA.pem

 the question: where does the serial number for this certificate come from?
 is it random by default when nothing is said about it?

 would this be also an option when using openssl like this:

 openssl ca -batch -config any.cnf -name any_ca -md sha256 -startdate ...
 -enddate ... 

 Thanks.

 --
 Best regards,
 Ing. Walter Höhlhubmer



 ___
 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] Bug 1.0.1f - selfsign ignores email_in_dn setting

[Ben Humpert]

2015-06-24 1:35 GMT+02:00 Jakob Bohm jb-open...@wisemo.com:
 On 19/06/2015 16:24, Ben Humpert wrote:

 When the CSR contains an email address and the email_in_dn setting in
 the config file is set to no the email address is actually present
 in the issuer DN but not in the subject DN. This causes errors when
 verifying certificate chains since the subject hash is used to
 identify a cert but the issuer hash is different.

 Are you sure, I have not seen this behavior in current
 versions when making self-signed certificates, could
 you provide step by step reproduction procedures to
 cause this misbehavior?

I have the openssl.cnf attached.

# Step-By-Step below #

cd /etc/ssl/
mv /etc/ssl/ca /etc/ssl/ca_orig
mkdir -p /etc/ssl/ca/db /etc/ssl/ca/private /etc/ssl/ca/certs
/etc/ssl/ca/crl /etc/ssl/ca/out /etc/ssl/ca/reqs
chmod 700 /etc/ssl/ca/private
cp /dev/null /etc/ssl/ca/db/RootCA.db
cp /dev/null /etc/ssl/ca/db/RootCA.db.attr
openssl rand -hex 16   /etc/ssl/ca/db/RootCA.crt.srl
echo 1001  /etc/ssl/ca/db/RootCA.crl.srl
cd /etc/ssl/ca/

openssl req -new -out /etc/ssl/ca/RootCA.csr
openssl ca -selfsign -in /etc/ssl/ca/RootCA.csr -out
/etc/ssl/ca/RootCA.crt -notext -startdate 15010100Z -enddate
191231235959Z

ln -s /etc/ssl/ca/RootCA.crt /etc/ssl/certs/`openssl x509 -hash -noout
-in RootCA.crt`.0

openssl verify /etc/ssl/ca/RootCA.crt

ln -s /etc/ssl/ca/RootCA.crt /etc/ssl/certs/`openssl x509 -issuer_hash
-noout -in RootCA.crt`.0

openssl verify /etc/ssl/ca/RootCA.crt

# Step-By-Step above #

# Cleanup below #

cd /etc/ssl/
rm -rf /etc/ssl/certs/`openssl x509 -hash -noout -in RootCA.crt`.0
rm -rf /etc/ssl/certs/`openssl x509 -issuer_hash -noout -in RootCA.crt`.0
rm -rf /etc/ssl/ca
mv /etc/ssl/ca_orig /etc/ssl/ca

# Cleanup above #

You cannot verify this certificate. OpenSSL always returns  error 20
at 0 depth lookup:unable to get local issuer certificate 

To prevent this, uncomment or completely delete the emailAddress line
in your certificate request.


openssl.cnf
Description: Binary data
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to verify a cert chain using Openssl command line?

[Ben Humpert]

Do you use nameConstraints or have specified IP in subjectAltName?
Because OpenSSL can't handle that correctly.

2015-06-29 22:51 GMT+02:00 David Li dlipub...@gmail.com:
 Hi,

 As a test, I have created a rootCA, a subCA (signed by the rootCA) and
 a client cert (signed by the subCA). Now I want to use verify,
 s_client and s_server to test them together.

 However I searched and tried a number of times but still unsure about
 the correct syntax format in verify command. This is what I did:

 cat rootCA.crt subCA.crt  caChain.crt

 openssl -verbose -verify -CAflie caChain.crt clientCert.crt

 openssl verify -CAfile caChain.crt client/clientCert.crt
 client/clientCert.crt: C = US, ST = California, O = David's company,
 CN = David's client cert, emailAddress = david...@example.com
 error 47 at 0 depth lookup:permitted subtree violation


 However it seems my s_client and s_server test is OK:

 I created a caChain by cancatenating rootCA and subCA together:

 Server:
 openssl s_server -cert server/serverComb.crt -www -CAfile caChain.crt -verify 
 3

 where serverComb.crt = cat of serverCert and server key

 Client:
 openssl s_client -CAfile caChina.crt -cert client/clientComb.crt

 where clientComb is  = cat of clientCert and clientKey


 Anyone has any idea why verify command failed?

 Thanks.
 ___
 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] How to verify a cert chain using Openssl command line?

[Ben Humpert]

Yes, because nameConstraints are inherited.

I don't know exactly where the bug lies but I strongly advise NOT to
use nameConstraints because while there is a standard nobody has
implemented full or correctly working support for it. I ran various
tests some weeks ago and the result was horrible. See
https://mta.openssl.org/pipermail/openssl-users/2015-May/001387.html
and https://mta.openssl.org/pipermail/openssl-users/2015-May/001388.html

2015-06-29 23:58 GMT+02:00 David Li dlipub...@gmail.com:
 The subCA  has nameConstraints in the subCA configuration file:

 [name_constraints]
 permitted;DNS.0 = example.com

 client configuration file has subjectAltName:
 subjectAltName = DNS: www.cs.com

 So is this a mismatch? How come s_client/s_server test was okay?





 On Mon, Jun 29, 2015 at 2:12 PM, Ben Humpert b...@an3k.de wrote:
 Do you use nameConstraints or have specified IP in subjectAltName?
 Because OpenSSL can't handle that correctly.

 2015-06-29 22:51 GMT+02:00 David Li dlipub...@gmail.com:
 Hi,

 As a test, I have created a rootCA, a subCA (signed by the rootCA) and
 a client cert (signed by the subCA). Now I want to use verify,
 s_client and s_server to test them together.

 However I searched and tried a number of times but still unsure about
 the correct syntax format in verify command. This is what I did:

 cat rootCA.crt subCA.crt  caChain.crt

 openssl -verbose -verify -CAflie caChain.crt clientCert.crt

 openssl verify -CAfile caChain.crt client/clientCert.crt
 client/clientCert.crt: C = US, ST = California, O = David's company,
 CN = David's client cert, emailAddress = david...@example.com
 error 47 at 0 depth lookup:permitted subtree violation


 However it seems my s_client and s_server test is OK:

 I created a caChain by cancatenating rootCA and subCA together:

 Server:
 openssl s_server -cert server/serverComb.crt -www -CAfile caChain.crt 
 -verify 3

 where serverComb.crt = cat of serverCert and server key

 Client:
 openssl s_client -CAfile caChina.crt -cert client/clientComb.crt

 where clientComb is  = cat of clientCert and clientKey


 Anyone has any idea why verify command failed?

 Thanks.
 ___
 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
 ___
 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

[openssl-users] Bug 1.0.1f - selfsign ignores email_in_dn setting

[Ben Humpert]

When the CSR contains an email address and the email_in_dn setting in
the config file is set to no the email address is actually present
in the issuer DN but not in the subject DN. This causes errors when
verifying certificate chains since the subject hash is used to
identify a cert but the issuer hash is different.

A dirty workaround is to 1) link the subject hash to the cert file and
additionally 2) link the issuer hash to the same cert file
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL.cnf File path

[Ben Humpert]

As a workaround try running openssl with the -config command line option.

2015-06-04 22:17 GMT+02:00 Cathy Fauntleroy cathy.fauntle...@vdtg.com:
 Hello,



 I have OpenSSL 1.0.2a installed on my Windows 7 box.  I am attempting to
 generate a CSR so new security certificates can be issued and am running
 into the following error when the command to generate the .csr file is
 issued from the C:\OpenSSL-Win64\bin directory:



 WARNING:  can't open config file: /usr/local/ssl/openssl.cnf

 Unable to load config info from /usr/local/ssl/openssl.cnf



 This is not a valid path on my Windows box…openssl.cnf resides in
 C:\OpenSSL-Win64\bin.  I verified the system PATH is correct also.  Any
 ideas?



 Thanks…

 Cathy




 ___
 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

[openssl-users] Bug in OpenSSL nameConstraints validation

[Ben Humpert]

Hi,

Based on 
https://tools.ietf.org/pdf/draft-wilson-wpkops-browser-processing-02.pdf
section 3.3.1.2. I ran my own tests. I wrote an email
(https://mta.openssl.org/pipermail/openssl-users/2015-May/001387.html)
with the results (attachments in
https://mta.openssl.org/pipermail/openssl-users/2015-May/001388.html).

I observed that OpenSSL s_client always throws Verify return code: 51
(unsupported name constraint type) when the name IP is present in the
subjectAltName extension. It does not do so when the name DNS is used
or when no subjectAltName extension is present at all.
In some situations it throws Verify return code: 47 (permitted
subtree violation) while there is no violation.

It was also clear that s_client does not check for nameConstraints
violation in CN at all.

However, OpenSSL itself behaves differently. I tried to EAP-TLS with
Android 4.4.4 and always got certificate unknown in the RADIUS log.
I did so too with eapol_test and noticed that OpenSSL does not send
the correct error to the server (This is another bug). The client
reported EAP: Status notification: local TLS alert (param=certificate
unknown) but additionally EAP: Status notification: remote
certificate verification (param=permitted subtree violation) and
OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed but
the server side always just received certificate unknown which is
like unknown error on windows.

With EAP-TLS I observed that (Ubuntu 14.04.2 server with OpenSSL
1.0.1f as well as Android 4.4.4) actually does check for
nameConstraints violation in CN. The used nameConstraints are

permitted;DNS.0=.lan
permitted;DNS.1=.local
permitted;DNS.3=.de
permitted;email.0=.de
permitted;IP.0=10.0.0.0/255.0.0.0
permitted;IP.1=172.16.0.0/255.240.0.0
permitted;IP.2=192.168.0.0/255.255.0.0

and the RADIUS server certificate subject is
/C=DE/ST=DE-BY/L=Munich/O=Example Company/CN=RADIUS
Server/emailAddress=r...@an3k.de with
subjectAltName=DNS:radius.home.lan,IP:10.11.12.13

The subtree violation that OpenSSL thinks has happened is not in
emailAddress or in subjectAltName. It is the CN field because RADIUS
Server is not ending on .lan .local or .de BUT s_client never
validated the CN field so why does OpenSSL so? Additionally RADIUS
Server is neither an IP address nor a DNS name, thus there is
actually no violation. And last but not least the subjectAltName
attribute is present, thus CN should not be validated at all!

This behavior is validated by testing a new server certificate/key but
without subjectAltName and another new cert/key without subjectAltName
but CN set to radius.home.lan.

Windows XP, Vista, 7, 8 and 10 as well as MacOS and iOS accepted the
initial RADIUS Server certificate. It is just OpenSSL doing some weird
stuff with nameConstraints validation.

Thank you very much in advance!


Best regards,

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

Re: [openssl-users] Android Wifi setup / CA certificate / always getting SSL fatal error

[Ben Humpert]

2015-05-27 8:17 GMT+02:00 Jakob Bohm jb-open...@wisemo.com:
 Maybe the Android user interface is really asking about
 something other than the issuing CA cert.

 What are you trying to achieve by selecting a CA cert
 in the client UI?

The official Google documentation as well as other sources say that it
asks for the Root CA certificate and with that selected I get a
different error message than with any other certificate so I guess it
is the right cert.

I want the users to validate the RADIUS server's certificate.

 Which OpenSSL version is the EAP_TLS code using to
 verify the certificates?

OpenSSL 1.0.1f 6 Jan 2014
built on: Thu Mar 19 15:12:02 UTC 2015
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions
-Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: /usr/lib/ssl

 I read somewhere on this list that an ultra-recent
 OpenSSL version (not sure if 1.0.2 or 1.1.0) was
 changed to be more tolerant of out-of-order certificates,
 though I am not sure if that change is also for the
 location of the peer certificate in the list, and if
 that change is also in the part used by EAP_TLS.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Android Wifi setup / CA certificate / always getting SSL fatal error

[Ben Humpert]

2015-05-27 14:02 GMT+02:00 Jakob Bohm jb-open...@wisemo.com:
 Just to clarify: The log messages in your original post,
 were those from Android or from the server?

These are from the RADIUS server debug output.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Android Wifi setup / CA certificate / always getting SSL fatal error

[Ben Humpert]

Hi everybody,

I have my RADIUS server running and Windows as well as MacOS and iOS
can successfully authenticate using EAP-PEAP, EAP-TTLS or EAP-TLS each
with server certificate validation. However, Android 4.4.4 can not and
I can't figure out why.

The complete Cert Chain:

Root CA
  - Intermediate CA1
- Intermediate CA2
  - Intermediate CA3
- Signing CA
  - RADIUS Server Cert
  - Android Client Cert

RADIUS server has the complete Certificate Chain in it's CA.crt file
and it's own certificate in it's server.crt file.

When I do not select any CA certificate in Android WiFi Setup but just
a User certificate EAP-TLS connection works fine. If I use the same
configuration but now select a CA certificate I get two different
errors.

When I select the Root CA certificate I get

Wed May 27 01:03:05 2015 : Debug: (106) eap: Peer sent method TLS (13)
Wed May 27 01:03:05 2015 : Debug: (106) eap: EAP TLS (13)
Wed May 27 01:03:05 2015 : Debug: (106) eap: Calling eap_tls to process EAP data
Wed May 27 01:03:05 2015 : Debug: (106) eap_tls: Authenticate
Wed May 27 01:03:05 2015 : Debug: (106) eap_tls: processing EAP-TLS
Wed May 27 01:03:05 2015 : Debug: (106) eap_tls: eaptls_verify returned 7
Wed May 27 01:03:05 2015 : Debug: (106) eap_tls: Done initial handshake
Wed May 27 01:03:05 2015 : Debug: (106) eap_tls:  TLS 1.0 Alert
[length 0002], fatal certificate_unknown
Wed May 27 01:03:05 2015 : ERROR: (106) eap_tls: TLS Alert
read:fatal:certificate unknown
Wed May 27 01:03:05 2015 : ERROR: (106) eap_tls: TLS_accept: Failed in
SSLv3 read client certificate A
Wed May 27 01:03:05 2015 : ERROR: (106) eap_tls: SSL says:
error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate
unknown
Wed May 27 01:03:05 2015 : Error: SSL: SSL_read failed inside of TLS
(-1), TLS session fails.
Wed May 27 01:03:05 2015 : Debug: TLS receive handshake failed during operation
Wed May 27 01:03:05 2015 : Debug: (106) eap_tls: eaptls_process returned 4
Wed May 27 01:03:05 2015 : ERROR: (106) eap: Failed continuing EAP TLS
(13) session. EAP sub-module failed

When I select any other CA certificate I always get

Wed May 27 01:05:21 2015 : Debug: (140) eap: Peer sent method TLS (13)
Wed May 27 01:05:21 2015 : Debug: (140) eap: EAP TLS (13)
Wed May 27 01:05:21 2015 : Debug: (140) eap: Calling eap_tls to process EAP data
Wed May 27 01:05:21 2015 : Debug: (140) eap_tls: Authenticate
Wed May 27 01:05:21 2015 : Debug: (140) eap_tls: processing EAP-TLS
Wed May 27 01:05:21 2015 : Debug: (140) eap_tls: eaptls_verify returned 7
Wed May 27 01:05:21 2015 : Debug: (140) eap_tls: Done initial handshake
Wed May 27 01:05:21 2015 : Debug: (140) eap_tls:  TLS 1.0 Alert
[length 0002], fatal unknown_ca
Wed May 27 01:05:21 2015 : ERROR: (140) eap_tls: TLS Alert read:fatal:unknown CA
Wed May 27 01:05:21 2015 : ERROR: (140) eap_tls: TLS_accept: Failed in
SSLv3 read client certificate A
Wed May 27 01:05:21 2015 : ERROR: (140) eap_tls: SSL says:
error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
Wed May 27 01:05:21 2015 : Error: SSL: SSL_read failed inside of TLS
(-1), TLS session fails.
Wed May 27 01:05:21 2015 : Debug: TLS receive handshake failed during operation
Wed May 27 01:05:21 2015 : Debug: (140) eap_tls: eaptls_process returned 4
Wed May 27 01:05:21 2015 : ERROR: (140) eap: Failed continuing EAP TLS
(13) session. EAP sub-module failed

All Windows, MacOS, iOS and Android devices have their own client
certificate and have all CA certificates installed.

Because of that I really have to ask what the funk is wrong with
Android? From all the tests I did not it feels like Android is sending
the certificates in the wrong order, so instead of sending the client
cert first it sends the CA cert first and thus RADIUS / OpenSSL errors
because it expected a client cert. Sadly I can't select the client
cert as a CA certificate or vice-versa.

Any help is much appreciated!


Best regards,

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

[openssl-users] Vulnerability logjam downgrades TLS connections to 512 Bit

[Ben Humpert]

Technical report: https://weakdh.org/imperfect-forward-secrecy.pdf

Check your browser (currently all are affected) at https://weakdh.org/

Check your Server at https://weakdh.org/sysadmin.html

Deploying Guide: https://weakdh.org/sysadmin.html
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] x509_config nameConstraints

[Ben Humpert]

Ok, after plenty of testing and some googling: the name constraints
extension is ... improvable. I ran plenty of tests but it looks like
that the extension is not very well implemented in todays browsers.

I have attached three txt files (DOS format) with the settings and
results of each test run. Between each test the browsers cache, etc.
was completely cleared and the browser got restarted. I validated the
used leaf certificates using serial number / hash and the signing CA
hash between each test run.

I used certificate warning if an error is shown but the user is
allowed to continue browsing and certificate error if the user is
NOT allowed to continue.

Results:
- Internet Explorer 11 does not understand the name IP in the
subjectAltName extension. However it understands the name DNS.
- Internet Explorer 11 just knows one certificate warning This
website's address doesn't match the address in the security
certificate regardless of why the certificate is invalid and no error
at all.

- (Test Run A.txt) nameConstraints extension NOT present
  - everything is fine

- (Test Run B.txt) nameConstraints extension present with
permitted;DNS and permitted;IP
  - OpenSSL s_client throws Verify return code: 51 (unsupported name
constraint type) whenever the name IP is present in the
subjectAltName extension. It does not do so when the name DNS is used
or when no subjectAltName extension is present at all. See Test B1,
B5, B8 and compare with Test B2, B3, B7
  - OpenSSL s_client throws Verify return code: 47 (permitted subtree
violation) while there is no violation. See Test B2
  - OpenSSL s_client does not check for nameConstraints violation in
CN at all. See Test B7, B10
  - Firefox does NOT check for nameConstraints violation in CN if
subjectAltName is present. See Test B5
  - Firefox just throws a warning ssl_error_bad_cert_domain instead
of an error when the certificate is used on a domain / ip address
which is not specified in the certificate. See Test B3, B4
  - Chrome throws an error Server's certificate is invalid when
there is no subjectAltName present but the ip address matches the
certificate CN. See Test B4

- (Test Run C.txt) nameConstraints extension present with
permitted;DNS and permitted;IP and permitted;dirName
  - Firefox throws an error sec_error_cert_not_in_name_space even
when the domain is specified in subjectAltName and no nameConstraints
violation exists. It's by the way the first time Internet Explorer
acted correctly ;). See Test C2
  - OpenSSL s_client throws Verify return code: 47 (permitted subtree
violation) while there is no violation. See Test C2
  - Chrome, Firefox (and for sure Internet Explorer) throwed an error
while there is no nameConstraints violation. Only OpenSSL s_client
acted correctly (but only because it doesn't check CN). See Test C4
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] x509_config nameConstraints

[Ben Humpert]

I love that when it happens :)

2015-05-12 16:56 GMT+02:00 Ben Humpert b...@an3k.de:
 Ok, after plenty of testing and some googling: the name constraints
 extension is ... improvable. I ran plenty of tests but it looks like
 that the extension is not very well implemented in todays browsers.

 I have attached three txt files (DOS format) with the settings and
 results of each test run. Between each test the browsers cache, etc.
 was completely cleared and the browser got restarted. I validated the
 used leaf certificates using serial number / hash and the signing CA
 hash between each test run.

 I used certificate warning if an error is shown but the user is
 allowed to continue browsing and certificate error if the user is
 NOT allowed to continue.

 Results:
 - Internet Explorer 11 does not understand the name IP in the
 subjectAltName extension. However it understands the name DNS.
 - Internet Explorer 11 just knows one certificate warning This
 website's address doesn't match the address in the security
 certificate regardless of why the certificate is invalid and no error
 at all.

 - (Test Run A.txt) nameConstraints extension NOT present
   - everything is fine

 - (Test Run B.txt) nameConstraints extension present with
 permitted;DNS and permitted;IP
   - OpenSSL s_client throws Verify return code: 51 (unsupported name
 constraint type) whenever the name IP is present in the
 subjectAltName extension. It does not do so when the name DNS is used
 or when no subjectAltName extension is present at all. See Test B1,
 B5, B8 and compare with Test B2, B3, B7
   - OpenSSL s_client throws Verify return code: 47 (permitted subtree
 violation) while there is no violation. See Test B2
   - OpenSSL s_client does not check for nameConstraints violation in
 CN at all. See Test B7, B10
   - Firefox does NOT check for nameConstraints violation in CN if
 subjectAltName is present. See Test B5
   - Firefox just throws a warning ssl_error_bad_cert_domain instead
 of an error when the certificate is used on a domain / ip address
 which is not specified in the certificate. See Test B3, B4
   - Chrome throws an error Server's certificate is invalid when
 there is no subjectAltName present but the ip address matches the
 certificate CN. See Test B4

 - (Test Run C.txt) nameConstraints extension present with
 permitted;DNS and permitted;IP and permitted;dirName
   - Firefox throws an error sec_error_cert_not_in_name_space even
 when the domain is specified in subjectAltName and no nameConstraints
 violation exists. It's by the way the first time Internet Explorer
 acted correctly ;). See Test C2
   - OpenSSL s_client throws Verify return code: 47 (permitted subtree
 violation) while there is no violation. See Test C2
   - Chrome, Firefox (and for sure Internet Explorer) throwed an error
 while there is no nameConstraints violation. Only OpenSSL s_client
 acted correctly (but only because it doesn't check CN). See Test C4
Ok, after plenty of testing and some googling: the name constraints extension 
is ... improvable.

My Structure:
- Root CA
  - Intermediate CA 1
- Intermediate CA 2
  - Intermediate CA 3
- Signing CA

The Intermediate CA 3 writes name constraints into the Signing CA's 
certificate. The web server provides certificates for all Intermediate CAs and 
the Signing CA in the correct order.

I didn't had any nameConstraints configured in these tests
###
Test A1

leaf certificate issued to  E = r...@an3k.de, CN = backup.an3k.lan, O = an3k 
Industries Ltd., L = Munich, S = DE-BY, C = DE 
subjectAltName=IP:10.11.12.13

- Google Chrome 42
  https://backup.an3k.lan   certification warning (Server's certificate 
does not match the URL)
  https://10.11.12.13   green lock

- Mozilla Firefox 37
  https://backup.an3k.lan   certification warning 
(ssl_error_bad_cert_domain)
  https://10.11.12.13   gray lock

- Internet Explorer 11
  https://backup.an3k.lan   black lock
  https://10.11.12.13   certification warning (This website's address 
doesn't match the address in the security certificate)

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client 
  https://10.11.12.13   Verify return code: 0 (ok)
###
Test A2 (need to test)

leaf certificate issued to  E = r...@an3k.de, CN = 10.11.12.13, O = an3k 
Industries Ltd., L = Munich, S = DE-BY, C = DE 
subjectAltName=DNS:backup.an3k.lan

- Google Chrome 42
  https://backup.an3k.lan   green lock
  https://10.11.12.13   certification warning (Server's certificate 
does not match the URL)

- Mozilla Firefox 37
  https://backup.an3k.lan   gray lock
  https://10.11.12.13   certification warning 
(ssl_error_bad_cert_domain)

- Internet Explorer 11
  https://backup.an3k.lan   black lock
  https://10.11.12.13   certification warning (This website's address 
doesn't match the address in the security certificate)

- OpenSSL 1.0.1f

[openssl-users] x509_config nameConstraints

[Ben Humpert]

Hi,

I read the OpenSSL Cookbook by Ivan Ristic and saw how he configured
nameConstraints so I adapted it for my setup.

First I tried the following but that doesn't work.

permitted;DNS.0=lan
permitted;DNS.1=local
permitted;IP.0=10.0.0.0/255.0.0.0
permitted;IP.1=172.16.0.0/255.240.0.0
permitted;IP.2=192.168.0.0/255.255.0.0
excluded;IP.3=0.0.0.0/0.0.0.0
excluded;IP.4=0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0

Then I thought maybe reordering might help like

excluded;IP.0=0.0.0.0/0.0.0.0
excluded;IP.1=0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0
permitted;DNS.0=lan
permitted;DNS.1=local
permitted;IP.2=10.0.0.0/255.0.0.0
permitted;IP.3=172.16.0.0/255.240.0.0
permitted;IP.4=192.168.0.0/255.255.0.0

but that gives the same result except that the ordering is different.
So I guess as soon as one permitted entry is specified everything else
is automatically excluded (vice-versa for excluded / permitted). If
that's the case the following configuration should only allow
certificates for any domain name using the TLDs lan or local and for
any IP address of one of the three private networks but everything
else will draw the certificate invalid. Is that correct?

permitted;DNS.0=lan
permitted;DNS.1=local
permitted;IP.0=10.0.0.0/255.0.0.0
permitted;IP.1=172.16.0.0/255.240.0.0
permitted;IP.2=192.168.0.0/255.255.0.0

If my assumption is correct, why does the CA/Browser Forum’s Baseline
Requirements define this? Do I have to do so because there's a bug
(somewhere) that permits certificates for IP addresses just because
DNS is permitted? Would I also have to exlcude email, URI, RID,
dirName and / or othername too?

Thank you very much in advance!


Best regards,

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

Re: [openssl-users] minor documentation errors

[Ben Humpert]

2015-05-09 21:47 GMT+02:00 Salz, Rich rs...@akamai.com:

 After getting into building and especially configuring my own CA again I'm
 nearly at the end and I've noticed some errors in the documentation I want
 to report.

 I like the again :)

Yeah, once upon a time I had done a comprehensive configuration with a
Root CA and two Signing CAs and wrote down the command lines I need to
use but then I didn't even touched it for over four years so I only
had few memories. A good PKI tutorial and my files helped me getting
into it again quickly.

 1) On https://www.openssl.org/docs/apps/ca.html for the -md option not all
 possible values (sha256, sha384, etc.) are list but just md5, sha1 and mdc2
 2) On https://www.openssl.org/docs/apps/req.html for the -[digest] option
 not all possible values are listed
 4) On https://www.openssl.org/docs/apps/req.html for the default_md
 option not all possible values are listed (shouldn't this reference the 
 -[digest]
 option)
 5) On https://www.openssl.org/docs/apps/x509.html not all available
 options are listed in -md2|-md5|-sha1|-mdc2

 Getting this correct is incredibly painful, as it depends on the 
 configuration options chosen when building openssl, and right now the 
 manpages are not affected by the config.  Our plan for this is to say any 
 supported digest.   That will be updated in a couple of days, and then 
 pushed to the website in hour or so later.

I see. I thought about mentioning get a list of supported (message)
digests by using the command  openssl list-message-digest-commands 
in the doc but after I tried that command I just got md4, md5, rmd160,
sha, sha1 but since I was able to create a sha-256 with the -sha256
command option I guess it's just the wrong command to get a list of
supported digest?

I also tried openssl list-message-digest-algorithms and that shows
SHA512, SHA256, whirlpool (I like that one) and more. However I don't
think that it shows the correct names of supported options
(case-sensitive?). Additionally some options are listed twice like
DSA, DSA-SHA, MD4, MD5. Is that a bug too?

While being on it I also issued openssl list-cipher-algorithms and
here all entries are listed twice. The output gives a list which
contains of list (B) appended to list (A). List (A) has 93 unique
entries and shows aliases uppercase (eg. CAMELLIA256 =
CAMELLIA-256-CBC). List (B) has 100 entries, 97 of them are unique.
Aliases are shown lowercase (camellia256 = CAMELLIA-256-CBC). The
additional entries are id-aes128-GCM, id-aes192-GCM, id-aes256-GCM and
blowfish = BF-CBC while the three aes ones are listed twice (once
correctly between AES-xxx-ECB and and AES-xxx-OFB once incorrectly
between DESX-CBC and rc2 = RC2-CBC).

 I also would like to ask if there's a newer version (or subtree) of openssl 
 that
 is cleaned up.

 I don't know what you mean by this.

Well I just asked because if that would've been planned I would've
liked to participate in that process. What I meant was a version
that's cleaned up of superseded / deprecated commands and has a more
logical structure or command names, eg. no CA command and not three
different ways of getting the same result. It's simple enough for
doing simple stuff like quickly getting a self-signed certificate and
just gets a little bit more complicated than it has so be when you
begin with complex stuff. But I don't have a problem with how it's
done now :)

 Currently there are many ways of creating a CSR, signing a
 certificate, etc. I think this is confusing everybody.

 The CA script is a wrapper around the various commands, and is reasonable.  
 But we're not planning on removing any of the current mechanisms.  Ivan 
 Ristic has a really great, free, OpenSSL cookbook that might be useful: 
 https://www.feistyduck.com/books/openssl-cookbook/

Thanks for that like. I'll definitely cook some delicious meals with that ;)
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] minor documentation errors

[Ben Humpert]

Hello list!

After getting into building and especially configuring my own CA again
I'm nearly at the end and I've noticed some errors in the
documentation I want to report.

1) On https://www.openssl.org/docs/apps/ca.html for the -md option not
all possible values (sha256, sha384, etc.) are list but just md5, sha1
and mdc2
2) On https://www.openssl.org/docs/apps/req.html for the -[digest]
option not all possible values are listed
3) On https://www.openssl.org/docs/apps/req.html the option -subj is
listed twice with a slightly different explanation
4) On https://www.openssl.org/docs/apps/req.html for the default_md
option not all possible values are listed (shouldn't this reference
the -[digest] option)
5) On https://www.openssl.org/docs/apps/x509.html not all available
options are listed in -md2|-md5|-sha1|-mdc2


I also would like to ask if there's a newer version (or subtree) of
openssl that is cleaned up. Currently there are many ways of creating
a CSR, signing a certificate, etc. I think this is confusing
everybody.

Thank you very much in advance.


Best regards,

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