Re: parsing invalid DER

[Peter Sylvester]

On 01/09/2022 18:15, Matt Caswell wrote:



On 01/09/2022 13:21, Dave Coombs via openssl-users wrote:

So!  Is it possible to work around these, using ASN1_MACRO trickery or
what-have-you?  It's pretty clear I should end up with an empty bit-
string and integer value 0x42, so is there a way to loosen the parser's
pickiness and achieve this?


Unfortunately, AFAIK, I don't think there is a way to do this.

Matt Hi,


I would try to patch two routines.

I vaguely remember that openssl's integer decoder was eating a leading 0 octet in a positive  
integer decoding.


  but that seems to be fixed.  code is in routine c2i_ibuf in 
crypto/asn1/a_int.c

0301xx    look what ossl_c2i_ASN1_BIT_STRING  in a_bitstr.c Don't test for bits 
when length is 1

Best

Peter

Re: Why does OpenSSL report google's certificate is "self-signed"?

[Peter Sylvester]

On 01/04/2021 16:21, Michael Wojcik wrote:

Thanks to everyone who responded. You've confirmed my impression:

- There doesn't appear to be any applicable standard which requires or forbids 
including the root, or even endorses or discourages it).


rfc8446  page 65:

     The sender's certificate MUST come in the first
   CertificateEntry in the list.  Each following certificate SHOULD
   directly certify the one immediately preceding it.  Because
   certificate validation requires that trust anchors be distributed
   independently, a certificate that specifies a trust anchor MAY be
   omitted from the chain, provided that supported peers are known to
   possess any omitted certificates.

   Note: Prior to TLS 1.3, "certificate_list" ordering required each
   certificate to certify the one immediately preceding it; however,
   some implementations allowed some flexibility.  Servers sometimes
   send both a current and deprecated intermediate for transitional
   purposes, and others are simply configured incorrectly, but these
   cases can nonetheless be validated properly.  For maximum
   compatibility, all implementations SHOULD be prepared to handle
   potentially extraneous certificates and arbitrary orderings from any
   TLS version, with the exception of the end-entity certificate which
   MUST be first.

Re: ASN.1 encoding error

[Peter Sylvester]

Even with sound this would not be BER. i:-) Integers can have 9 or more leading 
zero bits in BERnot

ISO/IEC 8825-1:2008 (E) ITU-T Rec. X.690 (11/2008)

7 8.3 Encoding of an integer value

8.3.1The encoding of an integer value shall be primitive. The contents octets shall consist of one 
or more octets.


8.3.2If  the  contents  octets  of  an  integer  value  encoding consist  of  more  than  one  
octet,  then  the  bits  of  the first  octet and bit 8 of the second octet: a) shall not all be 
ones; and


b) shall not all be zero.

NOTE – These rules ensure that an integer value is always encoded in the smallest possible number of 
octets.


8.3.3The contents octets shall be a two's complement binary number equal to the integer value, and 
consisting of bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second octet, followed 
by bits 8 to 1 of each octet in turn up to and including the last octet of the contents octets.


NOTE – The value of a two's complement binary number is derived by numbering the bits in the 
contents octets, starting with bit1 of the last octet as bit zero and ending the numbering with bit 
8 of the first octet. Each bit is assigned a numerical value of 2N, where  N  is  its  position  in  
the  above  numbering  sequence. The  value  of  the  two's  complement  binary  number  is 
obtained  by  summing the numerical values assigned to each bit for those bits which are set to one, 
excluding bit 8 of the first octet, and then reducing this value by the numerical value assigned to 
bit 8 of the first octet if that bit is set to one.








On 25/02/2021 18:28, Benjamin Kaduk via openssl-users wrote:

That sounds like the certificate is encoded using ASN.1 BER rules, that openssl
accepts, but the python library is insisting on DER encoding (per the spec).

-Ben

On Thu, Feb 25, 2021 at 05:19:32PM +, John Robson via openssl-users wrote:

Hi all,

I'm encountering an error connecting to a device which as far as I can see
has a reasonable certificate...

The error coming back (through twisted and python) is:


twisted.python.failure.Failure OpenSSL.SSL.Error: [('asn1 encoding
routines', 'c2i_ibuf', 'illegal padding'), ('asn1 encoding routines',
'asn1_template_noexp_d2i', 'nested asn1 error'), ('asn1 encoding routines',
'asn1_template_noexp_d2i', 'nested asn1 error'), ('SSL routines',
'tls_process_server_certificate', 'ASN1 lib')]

However if I run the following:
# openssl s_client -connect : /dev/null | openssl
x509 | openssl asn1parse
 0:d=0  hl=4 l= 733 cons: SEQUENCE
 4:d=1  hl=4 l= 453 cons: SEQUENCE
 8:d=2  hl=2 l=   3 cons: cont [ 0 ]
10:d=3  hl=2 l=   1 prim: INTEGER   :02
13:d=2  hl=2 l=   4 prim: INTEGER   :00
19:d=2  hl=2 l=  13 cons: SEQUENCE
21:d=3  hl=2 l=   9 prim: OBJECT:sha256WithRSAEncryption
... (continues)

...then OpenSSL seems to handle the whole certificate without problem, the
thing that looks "off" to me is the serial number being defined as
"00", rather than "00" (which I see on the self signed certificates
from other devices of this type).

Is that likely to be causing the issue?  It's ~20 years since I last had to
deal with ASN.1 properly, so I can't remember if using unnecessarily long
representations of integers is actually valid.

The raw ASN.1 looks ok I *think* (although I note that it has four bytes
specified) "02 04 00 00 00 00"


I'm at the point where I might just try to get it to generate a new
certificate and see if it does that with a single byte zero (as per the
other similar device I've been looking at)

Am I completely barking up the wrong tree, is there something else that I
can use other than the asn1parse option to figure out where the error might
be coming from?

Cheers,

John

--

*John Robson*

Re: building openssl-1.1.1d with "enable-deprecated"

[Peter Sui]

Hi Matt,
   I said " It does not work" means, after I build the open-ssl1.1.1d
with or without the "enable-deprecated" configuration, then use the
library, header files in my application as before with the older
version(1.0.2t), then my build failed, the errors are like:
Error C3861 'HMAC_CTX_init': identifier not found
Error C3861 'HMAC_CTX_cleanup': identifier not found
and more related to some struct def difference.
But as I imagine, it should not happen, right ?

Peter

On Mon, Sep 16, 2019 at 11:17 AM Michael Wojcik <
michael.woj...@microfocus.com> wrote:

> Matt has answered the main question, but as an aside:
> -D"_CRT_SECURE_NO_DEPRECATE" suppresses warning messages from Microsoft's
> Visual C compiler for using various standard C library functions, rather
> than using the optional "secure" ones (a misnomer, as they are at best
> somewhat easier to use safely) added with C99 (in Appendix K of the C
> standard, I think; I'm traveling and don't have my copy handy). It has
> nothing to do with OpenSSL APIs, deprecated or otherwise; it just reduces
> noise from the Microsoft compiler.
>

Re: building openssl-1.1.1d with "enable-deprecated"

[Peter Sui]

Hi Matt,
So you are saying configuring with "enable-deprecated" or not won't
make the build different, they are all actually support the deprecated
functions, right ? If yes, then in my application , if  I have
"OPENSSL_USE_DEPRECATED"
defined, the depecated functions in my application should still work,
right?  But it does not work. And as I imagine, in the openssl header
files(after a successful build), it should have some "#if defines
OPENSSL_USE_DEPRECATED"
like statement, but I don't see it anywhere, can you tell me how it works?

Thanks!

Peter

On Mon, Sep 16, 2019 at 10:52 AM Matt Caswell  wrote:

>
>
> On 16/09/2019 15:44, Peter Sui wrote:
> > Hi,
> >From the openssl website, I got the folloeing instruction:
> > "
> > Access to deprecated functions/macros has been removed by default. To
> enable
> > access you must do two things. 1) Build OpenSSL with deprecation support
> (pass
> > "enable-deprecated" as an argument to config) 2) Applications must define
> > "OPENSSL_USE_DEPRECATED" before including OpenSSL header files.
> > "
> > But, after I followed the instructions, it did not work. I searched all
> the
> > files(.h, .cpp, .c), I did not see the "OPENSSL_USE_DEPRECATED"
> anywhere. And
> > in the make file generated, I found it's using the
> > flag -D"_CRT_SECURE_NO_DEPRECATE", does it mean no deprecated functions
> > available in the library built?  I also compared all the binary and
> header files
> > between the build without "enable-deprecated" and the build
> > with "enable-deprecated", there is no difference.
> > The command I used is:
> > perl Configure VC-WIN32 enable-deprecated
> > --prefix=T:\openssl-%OPENSSL_VERSION%-32bit-release-DLL-VS2015
> > nmake
> >
>
> That CHANGES entry is incorrect and out-of-date. It should probably be
> removed.
> The original CHANGES entry said this:
>
>   *) config has been changed so that by default OPENSSL_NO_DEPRECATED is
> used.
>  Access to deprecated functions can be re-enabled by running config
> with
>  "enable-deprecated". In addition applications wishing to use
> deprecated
>  functions must define OPENSSL_USE_DEPRECATED. Note that this new
> behaviour
>  will, by default, disable some transitive includes that previously
> existed
>  in the header files (e.g. ec.h will no longer, by default, include
> bn.h)
>  [Matt Caswell]
>
> That CHANGES entry was added while 1.1.0 was being developed. However
> before
> 1.1.0 was released we changed our mind and added this CHANGES entry:
>
>   *) Revert default OPENSSL_NO_DEPRECATED setting.  Instead OpenSSL
>  continues to support deprecated interfaces in default builds.
>  However, applications are strongly advised to compile their
>  source files with -DOPENSSL_API_COMPAT=0x1010L, which hides
>  the declarations of all interfaces deprecated in 0.9.8, 1.0.0
>  or the 1.1.0 releases.
>
>  In environments in which all applications have been ported to
>  not use any deprecated interfaces OpenSSL's Configure script
>  should be used with the --api=1.1.0 option to entirely remove
>  support for the deprecated features from the library and
>  unconditionally disable them in the installed headers.
>  Essentially the same effect can be achieved with the "no-deprecated"
>  argument to Configure, except that this will always restrict
>  the build to just the latest API, rather than a fixed API
>  version.
>
>  As applications are ported to future revisions of the API,
>  they should update their compile-time OPENSSL_API_COMPAT define
>  accordingly, but in most cases should be able to continue to
>  compile with later releases.
>
>  The OPENSSL_API_COMPAT versions for 1.0.0, and 0.9.8 are
>  0x1000L and 0x00908000L, respectively.  However those
>  versions did not support the OPENSSL_API_COMPAT feature, and
>  so applications are not typically tested for explicit support
>  of just the undeprecated features of either release.
>  [Viktor Dukhovni]
>
> Regards
>
> Matt
>

RE: building openssl-1.1.1d with "enable-deprecated"

[Peter Sui]

Hi,
   From the openssl website, I got the folloeing instruction:
"
Access to deprecated functions/macros has been removed by default. To
enable access you must do two things. 1) Build OpenSSL with deprecation
support (pass "enable-deprecated" as an argument to config) 2) Applications
must define "OPENSSL_USE_DEPRECATED" before including OpenSSL header files.
"
But, after I followed the instructions, it did not work. I searched all the
files(.h, .cpp, .c), I did not see the "OPENSSL_USE_DEPRECATED"  anywhere.
And in the make file generated, I found it's using the
flag -D"_CRT_SECURE_NO_DEPRECATE", does it mean no deprecated functions
available in the library built?  I also compared all the binary and header
files between the build without "enable-deprecated" and the build with
"enable-deprecated",
there is no difference.
The command I used is:
perl Configure VC-WIN32 enable-deprecated
--prefix=T:\openssl-%OPENSSL_VERSION%-32bit-release-DLL-VS2015
nmake

Thank you inadvance!

Peter Sui

Re: Allow specifying the tag after AAD in CCM mode

[Peter Magnusson]

I've commented on the PR, mostly about not understanding the commit
message RFC-references and indentation error.

Overall the PR looks good to me, but I'd like someone who is more
familiar with implementation have a look at it.

Best Regards
Eine Kleine Blau Fisch

On Tue, Feb 19, 2019 at 2:10 PM Tobias Nießen  wrote:
>
> Hello everyone,
>
> in GCM and OCB mode, it is possible to set the authentication tag after
> supplying AAD, but the CCM implementation does not allow that. This
> isn't a problem for most applications, but in Node.js, we expose similar
> APIs to interact with AEAD ciphers and these differences between cipher
> modes within OpenSSL propagate to our users. Unless there is a reason
> for the current behavior, I would prefer to change it.
>
> I opened a PR about this five months ago
> (https://github.com/openssl/openssl/pull/7243). It has received zero
> attention and I am hoping the mailing list is a good way to change that.
>
> Kind regards,
> Tobias
>

Re: [openssl-users] File permissions on keys, csr, and certificates

[Peter Magnusson]

root:root, chmod 400. And ideally your Root CA files should not be
hosted on your web server, otherwise a server compromise also
compromises your root authority.

https://redmine.lighttpd.net/projects/1/wiki/docs_ssl
Permissions
Be careful to keep your .pem file private! Lighttpd reads all pemfiles
at startup, before dropping privileges. It is therefore best to make
the pem file owned by root and readable by root only:
$ chown root:root /etc/lighttpd/ssl/example.org.pem
$ chmod 400 /etc/lighttpd/ssl/example.org.pem
On Fri, Nov 9, 2018 at 10:04 PM Ikwyl6 via openssl-users
 wrote:
>
> Hi - I created a question on Super User about questions on file permissions 
> and what the file permissions should be on created files. See link here:
>
> https://superuser.com/questions/1368747/file-permissions-for-openssl-created-files-for-https-web-server-lighttpd
>
> Could someone comment on what file permissions should be on each file and who 
> should own them.
>
> Thank you.
> --
> 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] Is there any C code that implements SM2 algorithm separately?

[Peter Magnusson]

You can find a number of SM2 implementations on github, etc.

https://github.com/openssl/openssl/blob/9453b196343db579c590130adc63d35d2ff87188/crypto/sm2/sm2_crypt.c
https://github.com/ARMmbed/mbedtls/blob/3ea8c4cb2a03724ba15c915e02d83255e1884859/library/ecdsa.c
https://github.com/developerworks/sm2/blob/master/miracl/sm2.c

Asymmetric ciphers are typically not "library free", because you need
the big number operations. The big number operations should preferably
secure versions that don't reveal private key through side-channels
(timing etc), so these operations are usually are provided by a
cryptographic library.
On Fri, Nov 9, 2018 at 3:06 AM 朱明哲  wrote:
>
> Hi all,
>
> Is there any C code that implements SM2 algorithm separately, which means is 
> there a version in C language that is implemented independently of the 
> existing library of openssl?
> Thanks a lot.
>
> Best Wishes.
>
>
>
>
>
>
> --
> ___
> 朱明哲
> 电子邮箱：zhumz...@163.com
> 手机号码：15651609020
>
>
>
>
>
> --
> 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] openssl ca pkcs11 UI_set_result_ex:result too large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters

[Peter Magnusson]

Thanks =)

This is similar to other commands, e.g. ssh, tpm2-tools, etc
inconsistencies between different flags between different
sub-commands.

Getting it right the first time is easier said than done and changing
command line behaviour later on breaks user scripts etc.

//P
On Wed, Oct 17, 2018 at 10:13 AM Richard Levitte  wrote:
>
> In message 
>  on Tue, 
> 16 Oct 2018 10:34:31 +0200, Peter Magnusson  
> said:
>
> > Sorry, I am an idiot =)
>
> No you're not.
>
> > Problem resolved, user error.  -key was the problem and should not be
> > used as I showed.
> >
> > -key has a different meaning for openssl ca than for openssl req, so
> > my PIN was my -key argument. It got my keyfile from the openssl conf
> > file.
>
> And this is precisely why you're not an idiot.  We're not consistent
> between openssl sub-commands, so no wonder you get confused.  It's a
> pattern thing, we catch on to similar patterns (such as option names).
>
> We really should look over those options...  (but with all the other
> stuff we have going on, I'm afraid this isn't the highest on our
> priority list)
>
> Cheers,
> Richard
>
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> --
> 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] openssl ca pkcs11 UI_set_result_ex:result too large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters

[Peter Magnusson]

Sorry, I am an idiot =)

Problem resolved, user error.  -key was the problem and should not be
used as I showed.

-key has a different meaning for openssl ca than for openssl req, so
my PIN was my -key argument. It got my keyfile from the openssl conf
file.
On Tue, Oct 16, 2018 at 10:23 AM Richard Levitte  wrote:
>
> I'm curious about this error line from the 'openssl ca' output:
>
> > 140735853761408:error:28078064:UI routines:UI_set_result_ex:result too 
> > large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
>
> It should be interesting to try and figure out what pass phrased was
> passed and where it came from.  I'm afraid that's a debugging session.
>
> Cheers,
> Richard
>
> In message 
>  on Tue, 
> 16 Oct 2018 09:54:08 +0200, Peter Magnusson  
> said:
>
> > The error can be workaround by entering PIN = "..." into [pkcs11_section].
> > pkcs11 engine version is libp11-0.4.9.
> > Anyone know if this a 1) libp11 issue or 2) openssl issue or 3) me
> > doing something wrong?
> > On Mon, Oct 15, 2018 at 5:40 PM Peter Magnusson
> >  wrote:
> > >
> > > Hi,
> > >
> > > I'm trying to understand how to make "openssl ca" prompt for a PKCS#11
> > > login pin. Version is openssl-1.1.1.
> > >
> > > openssl req works as I would expect, prompting for PIN:
> > >
> > > YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
> > > local-build/bin/openssl \
> > >  req -config yubihsm2-openssl.conf -new \
> > >  -engine pkcs11 -keyform engine -key slot_0-label_ca_key -out
> > > certs.dir/ca.csr.pem
> > > engine "pkcs11" set.
> > > Enter PKCS#11 token PIN for YubiHSM:
> > >
> > > openssl ca I fail to get working, no prompt presented, tried adding
> > > -passin stdin but that has no effect.
> > >
> > > YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
> > >  local-build/bin/openssl ca -passin stdin -engine pkcs11 -keyform
> > > engine -key "pkcs11:token=YubiHSM;object=ca_key;type=private" \
> > >  -config yubihsm2-openssl.conf \
> > >  -days 3650 -extensions vpn_server_cert \
> > >  -out server.cert.pem \
> > >  -infiles ../server/certs.dir/server.csr.pem
> > > engine "pkcs11" set.
> > > Using configuration from yubihsm2-openssl.conf
> > > Login failed
> > > Login to token failed, returning NULL...
> > > PKCS11_get_private_key returned NULL
> > > cannot load CA private key from engine
> > > 140735853761408:error:28078064:UI routines:UI_set_result_ex:result too
> > > large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
> > > 140735853761408:error:82074007:PKCS#11 module:pkcs11_login:Invalid
> > > arguments:p11_slot.c:240:
> > > 140735853761408:error:26096080:engine
> > > routines:ENGINE_load_private_key:failed loading private
> > > key:crypto/engine/eng_pkey.c:78:
> > > unable to load CA private key
> > >
> > > Best Regards
> > > //P
> >
> --
> 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] openssl ca pkcs11 UI_set_result_ex:result too large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters

[Peter Magnusson]

The error can be workaround by entering PIN = "..." into [pkcs11_section].
pkcs11 engine version is libp11-0.4.9.
Anyone know if this a 1) libp11 issue or 2) openssl issue or 3) me
doing something wrong?
On Mon, Oct 15, 2018 at 5:40 PM Peter Magnusson
 wrote:
>
> Hi,
>
> I'm trying to understand how to make "openssl ca" prompt for a PKCS#11
> login pin. Version is openssl-1.1.1.
>
> openssl req works as I would expect, prompting for PIN:
>
> YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
> local-build/bin/openssl \
>  req -config yubihsm2-openssl.conf -new \
>  -engine pkcs11 -keyform engine -key slot_0-label_ca_key -out
> certs.dir/ca.csr.pem
> engine "pkcs11" set.
> Enter PKCS#11 token PIN for YubiHSM:
>
> openssl ca I fail to get working, no prompt presented, tried adding
> -passin stdin but that has no effect.
>
> YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
>  local-build/bin/openssl ca -passin stdin -engine pkcs11 -keyform
> engine -key "pkcs11:token=YubiHSM;object=ca_key;type=private" \
>  -config yubihsm2-openssl.conf \
>  -days 3650 -extensions vpn_server_cert \
>  -out server.cert.pem \
>  -infiles ../server/certs.dir/server.csr.pem
> engine "pkcs11" set.
> Using configuration from yubihsm2-openssl.conf
> Login failed
> Login to token failed, returning NULL...
> PKCS11_get_private_key returned NULL
> cannot load CA private key from engine
> 140735853761408:error:28078064:UI routines:UI_set_result_ex:result too
> large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
> 140735853761408:error:82074007:PKCS#11 module:pkcs11_login:Invalid
> arguments:p11_slot.c:240:
> 140735853761408:error:26096080:engine
> routines:ENGINE_load_private_key:failed loading private
> key:crypto/engine/eng_pkey.c:78:
> unable to load CA private key
>
> Best Regards
> //P
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] openssl ca pkcs11 UI_set_result_ex:result too large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters

[Peter Magnusson]

Hi,

I'm trying to understand how to make "openssl ca" prompt for a PKCS#11
login pin. Version is openssl-1.1.1.

openssl req works as I would expect, prompting for PIN:

YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
local-build/bin/openssl \
 req -config yubihsm2-openssl.conf -new \
 -engine pkcs11 -keyform engine -key slot_0-label_ca_key -out
certs.dir/ca.csr.pem
engine "pkcs11" set.
Enter PKCS#11 token PIN for YubiHSM:

openssl ca I fail to get working, no prompt presented, tried adding
-passin stdin but that has no effect.

YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
 local-build/bin/openssl ca -passin stdin -engine pkcs11 -keyform
engine -key "pkcs11:token=YubiHSM;object=ca_key;type=private" \
 -config yubihsm2-openssl.conf \
 -days 3650 -extensions vpn_server_cert \
 -out server.cert.pem \
 -infiles ../server/certs.dir/server.csr.pem
engine "pkcs11" set.
Using configuration from yubihsm2-openssl.conf
Login failed
Login to token failed, returning NULL...
PKCS11_get_private_key returned NULL
cannot load CA private key from engine
140735853761408:error:28078064:UI routines:UI_set_result_ex:result too
large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
140735853761408:error:82074007:PKCS#11 module:pkcs11_login:Invalid
arguments:p11_slot.c:240:
140735853761408:error:26096080:engine
routines:ENGINE_load_private_key:failed loading private
key:crypto/engine/eng_pkey.c:78:
unable to load CA private key

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

Re: [openssl-users] openssl commandline client use

[Peter Magnusson]

You would be better off with AES-CCM or such for your backup, that
gives you the integrity check.
 i.e. you would be reasonably sure what you decrypt is encrypted with your key.

So the fist question would be why even consider AES-CBC? Somewhere in
the decision process you ought to go "Is the major goal to support
very strange extremely limited legacy embedded environment where
library developers claims CBC is the only option?" and if no: don't
consider CBC. Since you are using OpenSSL, you clearly does not have
any problem that would give you a compelling reason to use CBC.

Using CBC in anything new design does not make much sense.
- CBC is weak against oracle attacks (online interactions with a
decryption oracle)
- CBC has no protection against modifications. If decryption succeeds,
you don't know if the resulting plaintext originated from

However - Your use-case as explained ( openssl enc -aes-256-cbc -k
mypass > backup.xb.gz.enc ) might not be a use-case where the AES-CBC
vulnerabilities are most dangerous though, if the decryption process
is a slow manual process. E.g. Padding oracle attacks against CBC
requires on average 128 decryption to crack one byte, and need an
online oracle (such as e.g. a backup decryption/restore service) to be
executed. With a human entering the decryption key manually for each
attempt, you'd expect the human to get suspicious with thousands of
decryption requests.  But as soon as you want to automate restore
functions and remove the human, you might enable oracle style attacks.

On Thu, Oct 11, 2018 at 6:45 AM Paul Chubb  wrote:
>
> Hi thanks for the responses. I try not to do crypto for the very reasons you 
> raise - i simply don't know enough and your (good) pointed questions have 
> demonstrated that.
>
>  Context:
>
> We are trying for GDPR and other privacy law compliance. We probably need to 
> meet GDPR, US requirements, Australian requirements, Japanese requirements 
> and UK requirements. The data is not hugely critical. It contains names and 
> exercise metrics. It doesn't contain credit card details or anything above 
> the level of names. I don't think it contains addresses but probably does 
> contain names of recognizable organisations which could provide a tuple for 
> identification purposes if the data was compromised.
>
> A mysqldump of the db in production at present is around 170Gb however that 
> is text based and we are using a binary solution based on percola xtrabackup 
> so the final size should be smaller for the current time. The documentation 
> on this by the backup software provider is very simplistic and simply pipes 
> the stream of data through openssl and then gzip:
>
> mariabackup --user=root --backup --stream=xbstream | gzip | openssl  enc 
> -aes-256-cbc -k mypass > backup.xb.gz.enc
>
> There are thousands of posts that do similar and in non-crypto circles it is 
> the accepted way of doing things. That was my starting point.
>
> I am  not using a password but generating keys. The symetric key is generated 
> by "openssl rand -hex 32" which I have read is suitable. The Nonce or IV is 
> generated  by "openssl rand -hex 16". These values are used once and then 
> kept for decryption of that file. They in turn are encrypted before storing - 
> see below.
>
> The two keys are held in ram while the backup occurs. They are applied to 
> openssl using the -K and -iv switches. They are then written out to disk. 
> encrypted with a list of public RSA keys and the original deleted from disk. 
> I then package it all up and delete the intervening encrypted files leaving 
> me with an archive with the encrypted backup and several copies of the nonce 
> and key each encrypted by different people's public keys.
>
> The backup regime has not been decided as yet. I expect it will be something 
> like a full backup per week and then either incrementals or differentials on 
> the other days. I expect that the fulls will be kept for 30 days and the 
> deltas for 14days. The database backups will sit on a secured server disk 
> which in turn will be backed up by the hosting provider with whatever process 
> and rotation they use.
>
> I would expect that headers in the backup stream would be predictable, 
> whether they provide a good enough attack surface I don't know. In addition 
> the clients of course know their data that may also provide an attack 
> surface. Finally I have included an encrypted file with a known plain text 
> phrase. Based on your comments, this will probably not get into production 
> but provides an easy way for testing and debugging to check that things are 
> encrypted or not.
>
> The kind of statements that prompted my question was: 
> https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup
>  whose comments suggest that openssl should never be used for production 
> purposes.Their suggestion was GnuPG which isn't suitable for this purpose 
> because it does password/key 

Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate

[Peter Magnusson]

> trust anchor -> self-issued root CA cert (i = 1) -> ... -> EE (i = n)

Yes that seems to be aligned with how the intended the path validation
algorithm should be applied, i.e. first certificate processed is the
cert of the trust anchor.  But it could be clearer, and wording
"recommended" (lowercase) does seem to imply implementers SHOULD
process trust anchor cert rather than MUST process it.

"  In Section 6.1, the text describes basic path validation.  Valid
   paths begin with certificates issued by a trust anchor.  The
   algorithm requires the public key of the CA, the CA's name, and any
   constraints upon the set of paths that may be validated using this
   key."

...

" Where a CA distributes self-signed certificates to specify trust
   anchor information, certificate extensions can be used to specify
   recommended inputs to path validation.  For example, a policy
   constraints extension could be included in the self-signed
   certificate to indicate that paths beginning with this trust anchor
   should be trusted only for the specified policies."


> https://github.com/openssl/openssl/pull/7353/commits/02804dbd04180bdb87046bcd7581f9ba9cb2baf3
> Does that address your concerns?

I think so! I'll integrate it into my tests and try to do Q/A on the
change, see if I can figure out any other edge case.

Best Regards
//P
On Mon, Oct 8, 2018 at 6:15 PM Viktor Dukhovni
 wrote:
>
> > On Oct 8, 2018, at 8:47 AM, Peter Magnusson 
> >  wrote:
> >
> > RFC5280 Certification Path Validation algorithm process from root to
> > leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> > Preparation for Certificate i+1 is expected to occur upon Root
> > certificate, i.e. the following should be expected behaviour:
> > * max_path_length=n (initialisation)
> > * max_path_length=n-1 (first decrement)
> > * max_path_length=0 (copied from root certificate constraint)
> > * VERIFY(max_path_length>0) error upon preparing transition from i=1
> > (Root) to i=2 (EvilCA).
>
> Well, strictly speaking, the trust-anchor is not part of the certificate
> chain in RFC5280, it is a public key and an issuer name, not a certificate
> in the chain.  However, when the trust-anchor is in the form of a self-signed
> CA certificate, one might take the view that this is a self-issued certificate
> to be included in the chain:
>
>  trust anchor -> self-issued root CA cert (i = 1) -> ... -> EE (i = n)
>
> in which case the "path lenth: 0" in the self-issed root CA cert precludes
> the root from issuing any subsidiary CAs that can in turn issue further
> EE certs.  That is perhaps reasonable, so I updated PR #7353 with
> a further commit:
>
>   
> https://github.com/openssl/openssl/pull/7353/commits/02804dbd04180bdb87046bcd7581f9ba9cb2baf3
>
> Does that address your concerns?
>
> --
> Viktor.
>
> --
> 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] Path Length Constraint ignored for Root and any self-issued certificate

[Peter Magnusson]

Tested mbedtls to see how other code bases handle thus.

mbedtls rejects the EvilCA certificate when connecting to openssl
s_server (as opposed to openssl c_client -verify that accepts the
connection).

Verify requested for (Depth 1):
cert. version : 3
serial number : 10:00
issuer name   : C=SE, ST=Root, L=Root, O=Root, OU=Root, CN=Root
subject name  : C=SE, ST=EvilCA, L=EvilCA, O=EvilCA, OU=EvilCA, CN=EvilCA
issued  on: 2018-10-08 08:20:21
expires on: 2028-10-05 08:20:21
signed using  : RSA with SHA-256
RSA key size  : 4096 bits
basic constraints : CA=true, max_pathlen=0
key usage : Key Cert Sign, CRL Sign
  ! The certificate is not correctly signed by the trusted CA

The handshake fails after this error, mbedtls_ssl_handshake returned -9984.
On Mon, Oct 8, 2018 at 2:51 PM Peter Magnusson
 wrote:
>
> sorry, typo on the verify line, this was what I should have written:
> VERIFY(max_path_length>0) error upon preparing transition from i=2
> (EvilCA) to i=2 (EvilServer).
> On Mon, Oct 8, 2018 at 2:47 PM Peter Magnusson
>  wrote:
> >
> > That is not correct behaviour as far as I can understand.
> >
> > RFC5280 Certification Path Validation algorithm process from root to
> > leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> > Preparation for Certificate i+1 is expected to occur upon Root
> > certificate, i.e. the following should be expected behaviour:
> > * max_path_length=n (initialisation)
> > * max_path_length=n-1 (first decrement)
> > * max_path_length=0 (copied from root certificate constraint)
> > * VERIFY(max_path_length>0) error upon preparing transition from i=1
> > (Root) to i=2 (EvilCA).
> >
> > OpenSSL does everything in a slightly different reverse algorithm, but
> > should perform the same controls and behaivor as the RFC imho.
> >
> > And aside from the RFC algorithm checking for this condition, it is
> > also analog with the description of the expected behaviour:
> >
> >The pathLenConstraint field is meaningful only if the cA boolean is
> >asserted and the key usage extension, if present, asserts the
> >keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
> >maximum number of non-self-issued intermediate certificates that may
> >follow this certificate in a valid certification path.  (Note: The
> >last certificate in the certification path is not an intermediate
> >certificate, and is not included in this limit.  Usually, the last
> >certificate is an end entity certificate, but it can be a CA
> >certificate.)  A pathLenConstraint of zero indicates that no non-
> >self-issued intermediate CA certificates may follow in a valid
> >certification path.  Where it appears, the pathLenConstraint field
> >MUST be greater than or equal to zero.  Where pathLenConstraint does
> >not appear, no limit is imposed.
> >
> > So my understanding is that the OpenSSL algorithm is confused and
> > fails to perform a check that is applicable to self-issued
> > certificates. The decrement of max_path_length (aka plen++ in OpenSSL
> > implementation) should not occur for self issued certificates, but the
> > validation of max_path_length>0 (aka plen>(constraint+1)) should
> > occur.
> > On Mon, Oct 8, 2018 at 1:27 PM J Decker  wrote:
> > >
> > > It was my interpretation that 0 pathlen on the root self signed meant 
> > > infinite.
> > > The pathlen only applies on the certs between root and the leaf (which 
> > > obviously can be 0, and CA true or not, but bad form to say true I'd 
> > > imagine.)
> > >
> > > On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson 
> > >  wrote:
> > >>
> > >> One more logic confusion in the OpenSSL Path Length Constraint check.
> > >> Any Path Length Constraint set by Root (or any other Self-Issued
> > >> Certificate) is ignored.
> > >> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
> > >> applied to the checker (i.e. the checker and the calculation logic
> > >> have been mixed up).
> > >>
> > >> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
> > >>
> > >> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
> > >> Certificate Sign, CRL Sign
> > >> X509v3 Basic Constraints: critical
> > >> CA:TRUE, pathlen:0
> > >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
> > >> Certific

Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate

[Peter Magnusson]

sorry, typo on the verify line, this was what I should have written:
VERIFY(max_path_length>0) error upon preparing transition from i=2
(EvilCA) to i=2 (EvilServer).
On Mon, Oct 8, 2018 at 2:47 PM Peter Magnusson
 wrote:
>
> That is not correct behaviour as far as I can understand.
>
> RFC5280 Certification Path Validation algorithm process from root to
> leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> Preparation for Certificate i+1 is expected to occur upon Root
> certificate, i.e. the following should be expected behaviour:
> * max_path_length=n (initialisation)
> * max_path_length=n-1 (first decrement)
> * max_path_length=0 (copied from root certificate constraint)
> * VERIFY(max_path_length>0) error upon preparing transition from i=1
> (Root) to i=2 (EvilCA).
>
> OpenSSL does everything in a slightly different reverse algorithm, but
> should perform the same controls and behaivor as the RFC imho.
>
> And aside from the RFC algorithm checking for this condition, it is
> also analog with the description of the expected behaviour:
>
>The pathLenConstraint field is meaningful only if the cA boolean is
>asserted and the key usage extension, if present, asserts the
>keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
>maximum number of non-self-issued intermediate certificates that may
>follow this certificate in a valid certification path.  (Note: The
>last certificate in the certification path is not an intermediate
>certificate, and is not included in this limit.  Usually, the last
>certificate is an end entity certificate, but it can be a CA
>certificate.)  A pathLenConstraint of zero indicates that no non-
>self-issued intermediate CA certificates may follow in a valid
>certification path.  Where it appears, the pathLenConstraint field
>MUST be greater than or equal to zero.  Where pathLenConstraint does
>not appear, no limit is imposed.
>
> So my understanding is that the OpenSSL algorithm is confused and
> fails to perform a check that is applicable to self-issued
> certificates. The decrement of max_path_length (aka plen++ in OpenSSL
> implementation) should not occur for self issued certificates, but the
> validation of max_path_length>0 (aka plen>(constraint+1)) should
> occur.
> On Mon, Oct 8, 2018 at 1:27 PM J Decker  wrote:
> >
> > It was my interpretation that 0 pathlen on the root self signed meant 
> > infinite.
> > The pathlen only applies on the certs between root and the leaf (which 
> > obviously can be 0, and CA true or not, but bad form to say true I'd 
> > imagine.)
> >
> > On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson 
> >  wrote:
> >>
> >> One more logic confusion in the OpenSSL Path Length Constraint check.
> >> Any Path Length Constraint set by Root (or any other Self-Issued
> >> Certificate) is ignored.
> >> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
> >> applied to the checker (i.e. the checker and the calculation logic
> >> have been mixed up).
> >>
> >> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
> >>
> >> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
> >> Certificate Sign, CRL Sign
> >> X509v3 Basic Constraints: critical
> >> CA:TRUE, pathlen:0
> >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
> >> Certificate Sign, CRL Sign
> >> X509v3 Basic Constraints: critical
> >> CA:TRUE, pathlen:0
> >> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
> >> X509v3 extensions:
> >> X509v3 Basic Constraints: critical
> >> CA:FALSE
> >> 
> >> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
> >> X509v3 extensions:
> >> X509v3 Subject Key Identifier:
> >> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >> --
> >> --
> >> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >> X509v3 Authority Key Identifier:
> >>
> >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
> >> X509v3 extensions:
> >> X509v3 Subject Key Identifier:
> >> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
&g

Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate

[Peter Magnusson]

That is not correct behaviour as far as I can understand.

RFC5280 Certification Path Validation algorithm process from root to
leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
Preparation for Certificate i+1 is expected to occur upon Root
certificate, i.e. the following should be expected behaviour:
* max_path_length=n (initialisation)
* max_path_length=n-1 (first decrement)
* max_path_length=0 (copied from root certificate constraint)
* VERIFY(max_path_length>0) error upon preparing transition from i=1
(Root) to i=2 (EvilCA).

OpenSSL does everything in a slightly different reverse algorithm, but
should perform the same controls and behaivor as the RFC imho.

And aside from the RFC algorithm checking for this condition, it is
also analog with the description of the expected behaviour:

   The pathLenConstraint field is meaningful only if the cA boolean is
   asserted and the key usage extension, if present, asserts the
   keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
   maximum number of non-self-issued intermediate certificates that may
   follow this certificate in a valid certification path.  (Note: The
   last certificate in the certification path is not an intermediate
   certificate, and is not included in this limit.  Usually, the last
   certificate is an end entity certificate, but it can be a CA
   certificate.)  A pathLenConstraint of zero indicates that no non-
   self-issued intermediate CA certificates may follow in a valid
   certification path.  Where it appears, the pathLenConstraint field
   MUST be greater than or equal to zero.  Where pathLenConstraint does
   not appear, no limit is imposed.

So my understanding is that the OpenSSL algorithm is confused and
fails to perform a check that is applicable to self-issued
certificates. The decrement of max_path_length (aka plen++ in OpenSSL
implementation) should not occur for self issued certificates, but the
validation of max_path_length>0 (aka plen>(constraint+1)) should
occur.
On Mon, Oct 8, 2018 at 1:27 PM J Decker  wrote:
>
> It was my interpretation that 0 pathlen on the root self signed meant 
> infinite.
> The pathlen only applies on the certs between root and the leaf (which 
> obviously can be 0, and CA true or not, but bad form to say true I'd imagine.)
>
> On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson 
>  wrote:
>>
>> One more logic confusion in the OpenSSL Path Length Constraint check.
>> Any Path Length Constraint set by Root (or any other Self-Issued
>> Certificate) is ignored.
>> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
>> applied to the checker (i.e. the checker and the calculation logic
>> have been mixed up).
>>
>> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
>>
>> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
>> Certificate Sign, CRL Sign
>> X509v3 Basic Constraints: critical
>> CA:TRUE, pathlen:0
>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
>> Certificate Sign, CRL Sign
>> X509v3 Basic Constraints: critical
>> CA:TRUE, pathlen:0
>> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
>> X509v3 extensions:
>> X509v3 Basic Constraints: critical
>> CA:FALSE
>> 
>> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
>> X509v3 extensions:
>> X509v3 Subject Key Identifier:
>> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> --
>> --
>> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> X509v3 Authority Key Identifier:
>>
>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
>> X509v3 extensions:
>> X509v3 Subject Key Identifier:
>> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>> --
>> --
>> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>> X509v3 Authority Key Identifier:
>>
>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
>> TLS Web Server Authentication
>> X509v3 Subject Key Identifier:
>> 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>> --
>> --
>> 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>>  

[openssl-users] Path Length Constraint ignored for Root and any self-issued certificate

[Peter Magnusson]

One more logic confusion in the OpenSSL Path Length Constraint check.
Any Path Length Constraint set by Root (or any other Self-Issued
Certificate) is ignored.
Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
applied to the checker (i.e. the checker and the calculation logic
have been mixed up).

https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2

openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE

openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
X509v3 extensions:
X509v3 Subject Key Identifier:
49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
--
--
49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
X509v3 Authority Key Identifier:

keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
X509v3 extensions:
X509v3 Subject Key Identifier:
B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
--
--
B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
X509v3 Authority Key Identifier:

keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
TLS Web Server Authentication
X509v3 Subject Key Identifier:
03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
--
--
03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
X509v3 Authority Key Identifier:

keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C

../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
root.pem -untrusted evilca.pem evilserver.pem
*** important variables ***
*** check_chain_extensions:524 i=0
*** check_chain_extensions:525 plen=0
*** check_chain_extensions:526 x->ex_pathlen=-1
*** if statement components ***
*** check_chain_extensions:528 i > 1=0
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:530 (x->ex_pathlen != -1)=0
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
*** important variables ***
*** check_chain_extensions:524 i=1
*** check_chain_extensions:525 plen=1
*** check_chain_extensions:526 x->ex_pathlen=0
*** if statement components ***
*** check_chain_extensions:528 i > 1=0
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:530 (x->ex_pathlen != -1)=1
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
*** important variables ***
*** check_chain_extensions:524 i=2
*** check_chain_extensions:525 plen=2
*** check_chain_extensions:526 x->ex_pathlen=0
*** if statement components ***
*** check_chain_extensions:528 i > 1=1
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
*** check_chain_extensions:530 (x->ex_pathlen != -1)=1
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=1
evilserver.pem: OK
Chain:
depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
EvilServer, CN = EvilServer (untrusted)
depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
= EvilCA (untrusted)
depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl verify accepting CA certs issued by intermediate with CA:TRUE, pathlen:0

[Peter Magnusson]

Thanks, I provided some input regarding off by one calculation of plen
still present in the patch.

You are very much correct on the definition of self-issued; rfc5280,
"A certificate is self-issued if the same DN appears in the subject
and issuer fields (the two DNs are the same if they match according to
the rules specified in Section 7.1)." Effectively path length
constraint is useless for limiting impact of a temporary CA breach, as
attacker can just issue an intermediate authority with a DN that
matches the definition of self-issued. The feature simply doesn't
provide the functionality I presumed it was it core purpose of
providing. It was very lucky for me I messed up my DN's so I could
learn that, thank you *very* much for your input, that was very useful
to be aware of!

Best Regards
//P
On Fri, Oct 5, 2018 at 7:10 AM Viktor Dukhovni
 wrote:
>
>
>
> > On Oct 4, 2018, at 6:25 AM, Viktor Dukhovni  
> > wrote:
> >
> > but this corner-case is not correct, the concept of "self-issued"
> > only applies to CAs, so for the leaf to be skipped it would have
> > the be a self-issued CA.  Try the patch below:
>
> I've simplified the patch in https://github.com/openssl/openssl/pull/7353
> please take a look.
>
> --
> Viktor.
>
> --
> 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] openssl verify accepting CA certs issued by intermediate with CA:TRUE, pathlen:0

[Peter Magnusson]

Your patch does seem to resolve the test case.

II have maximised confusion by generating a CSR with the same textual
information for EvilCA as EvilServer.

I don't think the chain includes any self signed certificates except the root;
73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6 (root, self issued)
DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70 issued by
73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6.
17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0 issued by
DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70.
1F:95:2F:26:9D:E1:37:BD:1F:9C:B5:51:FC:28:9C:EA:9F:1E:C8:B6 issued by
17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0.

Modulus of evilca.pem begins with 00:cd:ba:9f and modulus of
evilserver.pem begins with 00:af:83:6f, so they are different even if
both have  Subject: C=SE, ST=EvilServer, L=EvilServer, O=EvilServer,
OU=EvilServer, CN=EvilServer.

Funnily enough I don't trigger the edge case on regenerated files with
correct Subject information.

openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
X509v3 extensions:
X509v3 Subject Key Identifier:
73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6
--
--
73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6
X509v3 Authority Key Identifier:

keyid:73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6
openssl x509 -text -in intermediate.pem | egrep -a1 "X509v3 .* Key Identifier"
X509v3 extensions:
X509v3 Subject Key Identifier:
DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70
--
--
DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70
X509v3 Authority Key Identifier:

keyid:73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6
openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
X509v3 extensions:
X509v3 Subject Key Identifier:
17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0
--
--
17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0
X509v3 Authority Key Identifier:

keyid:DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70
openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
TLS Web Server Authentication
X509v3 Subject Key Identifier:
1F:95:2F:26:9D:E1:37:BD:1F:9C:B5:51:FC:28:9C:EA:9F:1E:C8:B6
--
--
1F:95:2F:26:9D:E1:37:BD:1F:9C:B5:51:FC:28:9C:EA:9F:1E:C8:B6
X509v3 Authority Key Identifier:

keyid:17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0
On Thu, Oct 4, 2018 at 12:26 PM Viktor Dukhovni
 wrote:
>
> On Wed, Oct 03, 2018 at 07:16:51PM +0200, Peter Magnusson wrote:
>
> > The following test case attempts to validates evilserver.pem, issued
> > by evilca.pem.
>
> More specifically, we see that in this test the leaf server certificate
> has the same subject and issuer, so EXFLAG_SI is set for that
> certificate, and it did not count in the path length:
>
> $ /usr/local/bin/openssl verify -show_chain -verbose -trusted root.pem 
> -untrusted untrusted.pem evilserver.pem
> evilserver.pem: OK
> Chain:
> depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU = 
> EvilServer, CN = EvilServer (untrusted)
> depth=1: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU = 
> EvilServer, CN = EvilServer (untrusted)
> depth=2: C = SE, ST = Intermediate, O = Intermediate, OU = Intermediate, 
> CN = Intermediate (untrusted)
> depth=3: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
>
> but this corner-case is not correct, the concept of "self-issued"
> only applies to CAs, so for the leaf to be skipped it would have
> the be a self-issued CA.  Try the patch below:
>
> --
> Viktor.
>
> diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c
> index 3a60d412da..77ca325d54 100644
> --- a/crypto/x509/x509_vfy.c
> +++ b/crypto/x509/x509_vfy.c
> @@ -445,6 +445,7 @@ static int check_chain_extensions(X509_STORE_CTX *ctx)
>  int i, must_be_ca, plen = 0;
>  X509 *x;
>  int proxy_path_length = 0;
> +int is_ca;
>  int purpose;
>  int allow_proxy_certs;
>  int num = sk_X509_num(ctx->chain);
> @@ -484,7 +485,7 @@ static int check_chain_extensions(X509_STORE_CTX *ctx)
>  X509_V_ERR_PROXY_CERTIFICATES_NOT_ALLOWED))
>  return 0;
>  }
> -ret = X509_check_ca(x);
> +ret = is_ca = X509_check_ca(x);
>  switch (must_be_ca) {
>  case -1:
>  if ((ctx->param->flags & X509_V_FLAG_X509_STRICT)
> @@ 

Re: [openssl-users] openssl verify accepting CA certs issued by intermediate with CA:TRUE, pathlen:0

[Peter Magnusson]

Is this expected?  (plen > (x->ex_pathlen + proxy_path_length + 1))
evaluates to false (constraint not violated) when checking constraint
0 against plen=1 (constraint violated as far as I can understand?).

Doesn't make much sense to me. Is there something I haven't understood
about how the constraint is supposed to work?

*** important variables ***
*** check_chain_extensions:523 i=0
*** check_chain_extensions:524 plen=0
*** check_chain_extensions:525 x->ex_pathlen=-1
*** if statement components ***
*** check_chain_extensions:527 i > 1=0
*** check_chain_extensions:528 !(x->ex_flags & EXFLAG_SI)=0
*** check_chain_extensions:529 (x->ex_pathlen != -1)=0
*** check_chain_extensions:530 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
*** important variables ***
*** check_chain_extensions:523 i=1
*** check_chain_extensions:524 plen=0
*** check_chain_extensions:525 x->ex_pathlen=-1
*** if statement components ***
*** check_chain_extensions:527 i > 1=0
*** check_chain_extensions:528 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:529 (x->ex_pathlen != -1)=0
*** check_chain_extensions:530 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
*** important variables ***
*** check_chain_extensions:523 i=2
*** check_chain_extensions:524 plen=1
*** check_chain_extensions:525 x->ex_pathlen=0
*** if statement components ***
*** check_chain_extensions:527 i > 1=1
*** check_chain_extensions:528 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:529 (x->ex_pathlen != -1)=1
*** check_chain_extensions:530 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
*** important variables ***
*** check_chain_extensions:523 i=3
*** check_chain_extensions:524 plen=2
*** check_chain_extensions:525 x->ex_pathlen=1
*** if statement components ***
*** check_chain_extensions:527 i > 1=1
*** check_chain_extensions:528 !(x->ex_flags & EXFLAG_SI)=0
*** check_chain_extensions:529 (x->ex_pathlen != -1)=1
*** check_chain_extensions:530 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl verify accepting CA certs issued by intermediate with CA:TRUE, pathlen:0

[Peter Magnusson]

The following test case attempts to validates evilserver.pem, issued
by evilca.pem.

evil*.pem is violating:
1/ pathlen=0 constraint of the compromised intermediate.pem (issuer of
evilserver.pem)
2/ pathlen=1 constraint of the non-compromised root-ca.pem (issuer of
intermediate.pem)

The particular example execution is from Mac (LibreSSL) but same
behaviour observed with e.g. homebrew as well.

https://github.com/blaufish/openssl-pathlen

openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:1
openssl x509 -text -in intermediate.pem | grep -a1 "X509v3 Basic"
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"

X509v3 Basic Constraints: critical
CA:TRUE
openssl verify -verbose -CAfile root.pem -untrusted untrusted.pem evilserver.pem
evilserver.pem: OK


On Wed, Oct 3, 2018 at 4:51 PM Viktor Dukhovni
 wrote:
>
> On Wed, Oct 03, 2018 at 02:51:57PM +0200, Peter Magnusson wrote:
>
> > $ openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem 
> > evil.pem
> > evil.pem: OK
>
> This is expected to work when intermediate.pem has pathlen 0, because
> you're verifying "evil.pem" as a *leaf* certificate, its CA:true
> is irrelevant when it is the last (leaf) certificate in the chain.
>
> An actually unexpected result would be:
>
> $ openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem 
> -untrusted evil.pem badee.pem
> badee.pem: OK
>
> where badee.pem is signed by evil.pem.  The path length constraint
> is not a constraint against issuing EE certs with CA:true, it only
> constraints the number additional intermediate (non-self-issued)
> CAs in a valid path.  In your example that number is zero.
>
>https://tools.ietf.org/html/rfc5280#section-4.2.1.9
>
>The pathLenConstraint field is meaningful only if the cA boolean is
>asserted and the key usage extension, if present, asserts the
>keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
>maximum number of non-self-issued intermediate certificates that may
>follow this certificate in a valid certification path.
>
> --
> Viktor.
> --
> 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] openssl verify accepting CA certs issued by intermediate with CA:TRUE, pathlen:0

[Peter Magnusson]

Hi,
It is my understanding "openssl verify" should raise
X509_V_ERR_PATH_LENGTH_EXCEEDED should be raised if pathlen=0
intermediate issues a new CA, but that does not seem to occur when I
test with a couple pf openssl versions.

I am not sure due to limited understanding of the code, but I am
wonder if there isn't an off-by-one or out-of-order increment error in
x509_vfy.c in this check: (plen > (x->ex_pathlen + proxy_path_length +
1))). if plen=1 and x->ex_pathlen=0, the check would become 1>1
(false) while it was expected to raise an error?

openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem evil.pem
evil.pem: OK

openssl x509 -text -in root.pem | egrep -a1 X509v3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
A5:70:7B:56:F1:93:E9:CC:FD:15:EF:FA:64:67:41:99:6F:40:DA:C5
--
--
A5:70:7B:56:F1:93:E9:CC:FD:15:EF:FA:64:67:41:99:6F:40:DA:C5
X509v3 Authority Key Identifier:

keyid:A5:70:7B:56:F1:93:E9:CC:FD:15:EF:FA:64:67:41:99:6F:40:DA:C5
--
--
X509v3 Key Usage:
Certificate Sign, CRL Sign
--
--
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:1


openssl x509 -text -in intermediate.pem | egrep -a1 X509v3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
B5:5A:8A:64:CE:A4:1E:51:6F:AB:E4:8E:E3:71:8D:EF:2D:42:A7:AD
--
--
B5:5A:8A:64:CE:A4:1E:51:6F:AB:E4:8E:E3:71:8D:EF:2D:42:A7:AD
X509v3 Authority Key Identifier:

keyid:A5:70:7B:56:F1:93:E9:CC:FD:15:EF:FA:64:67:41:99:6F:40:DA:C5
--
--
X509v3 Key Usage:
Certificate Sign, CRL Sign
--
--
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0


openssl x509 -text -in evil.pem | egrep -a1 X509v3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
81:3A:5A:BD:9E:6C:08:0F:C7:6A:31:A2:0D:0F:2A:02:62:BE:63:12
--
--
81:3A:5A:BD:9E:6C:08:0F:C7:6A:31:A2:0D:0F:2A:02:62:BE:63:12
X509v3 Authority Key Identifier:

keyid:B5:5A:8A:64:CE:A4:1E:51:6F:AB:E4:8E:E3:71:8D:EF:2D:42:A7:AD
--
--
X509v3 Basic Constraints: critical
CA:TRUE
--
--
CA:TRUE
X509v3 Key Usage:
Certificate Sign, CRL Sign
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] building openssl 1.1.1 using CrystaX NDK 10.3.2 (Android)

[Peter Petrik]

c aes-armv4.S bsaes-armv7.S aesv8-armx.S",
aes_obj => "aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o",
apps_aux_src => "",
apps_init_src => "",
apps_obj => "",
bf_asm_src => "bf_enc.c",
bf_obj => "bf_enc.o",
bin_cflags => "-pie",
bn_asm_src => "bn_asm.c armv4-mont.S armv4-gf2m.S",
bn_obj => "bn_asm.o armv4-mont.o armv4-gf2m.o",
bn_ops => "BN_LLONG RC4_CHAR",
build_file => "Makefile",
build_scheme => [ "unified", "unix" ],
cast_asm_src => "c_enc.c",
cast_obj => "c_enc.o",
cflags => "-pthread  -mandroid 
--sysroot=\$(ANDROID_NDK)/platforms/android-16/arch-arm",
chacha_asm_src => "chacha-armv4.S",
chacha_obj => "chacha-armv4.o",
cmll_asm_src => "camellia.c cmll_misc.c cmll_cbc.c",
cmll_obj => "camellia.o cmll_misc.o cmll_cbc.o",
cppflags => "",
cpuid_asm_src => "armcap.c armv4cpuid.S",
cpuid_obj => "armcap.o armv4cpuid.o",
cxxflags => "-std=c++11 -pthread  -mandroid 
--sysroot=\$(ANDROID_NDK)/platforms/android-16/arch-arm",
defines => [  ],
des_asm_src => "des_enc.c fcrypt_b.c",
des_obj => "des_enc.o fcrypt_b.o",
disable => [  ],
dso_extension => ".so",
dso_scheme => "dlfcn",
ec_asm_src => "ecp_nistz256.c ecp_nistz256-armv4.S",
ec_obj => "ecp_nistz256.o ecp_nistz256-armv4.o",
enable => [  ],
ex_libs => "-ldl -pthread",
exe_extension => "",
includes => [  ],
keccak1600_asm_src => "keccak1600-armv4.S",
keccak1600_obj => "keccak1600-armv4.o",
lflags => "",
lib_cflags => "",
lib_cppflags => "-DOPENSSL_USE_NODELETE",
lib_defines => [  ],
md5_asm_src => "",
md5_obj => "",
modes_asm_src => "ghash-armv4.S ghashv8-armx.S",
modes_obj => "ghash-armv4.o ghashv8-armx.o",
module_cflags => "-fPIC",
module_cxxflags => "",
module_ldflags => "-Wl,-znodelete -shared -Wl,-Bsymbolic",
padlock_asm_src => "",
padlock_obj => "",
perlasm_scheme => "void",
poly1305_asm_src => "poly1305-armv4.S",
poly1305_obj => "poly1305-armv4.o",
rc4_asm_src => "rc4_enc.c rc4_skey.c",
rc4_obj => "rc4_enc.o rc4_skey.o",
rc5_asm_src => "rc5_enc.c",
rc5_obj => "rc5_enc.o",
rmd160_asm_src => "",
rmd160_obj => "",
sha1_asm_src => "sha1-armv4-large.S sha256-armv4.S sha512-armv4.S",
sha1_obj => "sha1-armv4-large.o sha256-armv4.o sha512-armv4.o",
shared_cflag => "-fPIC",
shared_defflag => "-Wl,--version-script=",
shared_defines => [  ],
shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)",
shared_extension_simple => ".so",
shared_ldflag => "-Wl,-znodelete -shared -Wl,-Bsymbolic",
shared_rcflag => "",
shared_sonameflag => "-Wl,-soname=",
shared_target => "linux-shared",
thread_defines => [  ],
thread_scheme => "pthreads",
unistd => "",
uplink_aux_src => "",
uplink_obj => "",
wp_asm_src => "wp_block.c",
wp_obj => "wp_block.o",

Recorded environment:

AR = 
BUILDFILE = 
CC = 
CROSS_COMPILE = -
CXX = ccache arm-linux-androideabi-g++ -DANDROID -mandroid  
-fomit-frame-pointer --sysroot 
/opt/crystax-ndk-10.3.2/platforms/android-16/arch-arm 
-I/home/peter/quick/OSGeo4A/stage/armeabi-v7a/include 
-L/opt/crystax-ndk-10.3.2/sources/crystax/libs/armeabi-v7a -march=armv7-a 
-mfloat-abi=softfp -mfpu=vfp -mthumb -isystem 
/opt/crystax-ndk-10.3.2/sources/cxx-stl/gnu-libstdc++/4.9/include   
 -isystem 
/opt/crystax-ndk-10.3.2/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include
-isystem 
/opt/crystax-ndk-10.3.2/platforms/android-16/arch-arm/usr/include
HASHBANGPERL = 
OPENSSL_LOCAL_CONFIG_DIR = 
PERL = 
RANLIB = arm-linux-androideabi-ranlib
RC = 
WINDRES = 
__CNF_CFLAGS =  -march=armv7-a
__CNF_CPPDEFINES = 
__CNF_CPPFLAGS = 
__CNF_CPPINCLUDES = 
__CNF_CXXFLAGS =  -march=armv7-a
__CNF_LDFLAGS = 
__CNF_LDLIBS = 

Makevars:

AR  = arm-linux-androideabi-ar
ARFLAGS = r
CC  = arm-linux-a

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

[Peter Sylvester]

On 08/18/2017 07:16 PM, Dr. Stephen Henson wrote:
> On Thu, Aug 17, 2017, Robert Moskowitz wrote:
>
>> 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
What about:

[ req_distinguished_name ]
countryName = "Country Nmae (e.g. FR)"
countryName_value = $ENV::countryName
stateOrProvinceName = "State or Province"
stateOrProvinceName_value = $ENV::stateOrProvinceName

 

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

Re: [openssl-users] French Declaration

[Peter Sylvester Edelweb]

Two points:

- you use function xyz of openssl (is the implementation safe?)
- the purpose of using this in your application is "saving peanuts". what are 
peanuts?

/P



On 12/01/2016 08:29 PM, Brian Jost wrote:
Ok thanks, so there isn't a generic declaration that applications using openssl 
standard encryption like GCM can use? Each application will have to get self 
declared?

On Thu, Dec 1, 2016 at 12:12 PM, Peter Sylvester Edelweb 
<peter.sylves...@edelweb.fr<mailto:peter.sylves...@edelweb.fr>> wrote:
Hi

There are news since about a year.

https://www.ssi.gouv.fr/administration/reglementation/controle-reglementaire-sur-la-cryptographie/
There is a downloadable editable PDF to prepare the declaration.

Anyway, you normally do not declare all functionality of the openssl library if 
you use it in a product.

It may be as simple as "to hash passwords we use the SHAnnn functions as 
implemented by openssl".

I used to make such declarations about 15 years ago.


Peter








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

Re: [openssl-users] French Declaration

[Peter Sylvester Edelweb]

Hi

There are news since about a year.

https://www.ssi.gouv.fr/administration/reglementation/controle-reglementaire-sur-la-cryptographie/
There is a downloadable editable PDF to prepare the declaration.

Anyway, you normally do not declare all functionality of the openssl library if 
you use it in a product.

It may be as simple as "to hash passwords we use the SHAnnn functions as 
implemented by openssl".

I used to make such declarations about 15 years ago.


Peter






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

[openssl-users] OCSP verification issue

[Peter Bowen]

I recently ran into a bug with verification of OCSP responses that appears to 
be in all versions of OpenSSL (including current 1.1.0 builds).

RFC 6960 and its predecessor 2560 allow that the response may be signed by the 
key for "the CA who issued the certificate in question” (section 2.2).  In this 
case it should not be necessary to include any certs in the basicResponse, as 
the signature can be validated using the public key used to validate the 
certificate whose status is being checked.

While this is contemplated by the RFCs, OpenSSL fails in certain cases if no 
certificates are provided in the response. If there are at least two 
intermediate CAs in the certificate chain between a trust anchor and end entity 
certificate, then OCSP_basic_verify will return a certificate verify error.

The code below reproduces the failure and demonstrates that reducing the path 
length from anchor to end entity certificate resolves the issue as does adding 
a certificate from the trust anchor to the first CA to the response.

I think the correct behaviour would be to check if the issuer of the 
certificate matches the signer of the OCSP response and, if so, simply skip the 
X509_verify_cert check.

Thanks,
Peter

#!/usr/bin/env ruby
# Copyright 2016 Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# Licensed under the OpenSSL license (the "License").  You may not use
# this file except in compliance with the License.  You can obtain a copy
# in the file LICENSE in the source distribution or at
# https://www.openssl.org/source/license.html

require 'openssl'
require 'base64'
require 'open3'

# Ruby has no to_text method for OCSP responses, so shell out
def ocsp_to_text(ocsp_der)
  # Figure out if our base64 uses -D or -d to decode
  %x/echo | base64 -D/
  if $? == 0
dparam="-D"
  else
dparam="-d"
  end

  out = ""
  Open3::popen2("/bin/bash -t") do |i, o, t|
i.puts("openssl ocsp -noverify -text -respin <(echo 
#{Base64.strict_encode64(ocsp_der)} | base64 #{dparam})")
o.each{|l|out += l}
  end
  out
end

# Set up Names and Keys for all the certs
nodes = {
  :root => {
:name => OpenSSL::X509::Name.new([["C", "US", 
OpenSSL::ASN1::PRINTABLESTRING],
  ["O", "Beyond Hypersecure Inc", OpenSSL::ASN1::PRINTABLESTRING],
  ["CN", "Beyond Hypersecure Root CA", 
OpenSSL::ASN1::PRINTABLESTRING]]),
:key => OpenSSL::PKey::RSA.new(2048)
  },
  :ca1 => {
:name => OpenSSL::X509::Name.new([["C", "US", 
OpenSSL::ASN1::PRINTABLESTRING],
  ["O", "Beyond Hypersecure Inc", OpenSSL::ASN1::PRINTABLESTRING],
  ["CN", "Beyond Hypersecure Partner CA", 
OpenSSL::ASN1::PRINTABLESTRING]]),
:key => OpenSSL::PKey::RSA.new(2048)
  },
  :ca2 => {
:name => OpenSSL::X509::Name.new([["C", "US", 
OpenSSL::ASN1::PRINTABLESTRING],
  ["O", "HyperCyberHost LLC", OpenSSL::ASN1::PRINTABLESTRING],
  ["CN", "HyperCyberHost Server CA", 
OpenSSL::ASN1::PRINTABLESTRING]]),
:key => OpenSSL::PKey::RSA.new(2048)
  },
  :ee => {
:name => OpenSSL::X509::Name.new([["C", "US", 
OpenSSL::ASN1::PRINTABLESTRING],
  ["CN", "localdemo.sslmap.com", OpenSSL::ASN1::PRINTABLESTRING]]),
:key => OpenSSL::PKey::RSA.new(2048),
:sans => "DNS:localdemo.sslmap.com"
  }
}

# Generate all the certs
root_cert = OpenSSL::X509::Certificate.new
root_cert.version = 0x2
root_cert.serial = 0x0
root_cert.not_before = Time.new(2004,01,01,00,00,01)
root_cert.not_after =  Time.new(2028,12,31,23,59,59)
root_cert.subject = nodes[:root][:name]
root_cert.issuer = root_cert.subject
root_cert.public_key = nodes[:root][:key]
ef = OpenSSL::X509::ExtensionFactory.new
ef.subject_certificate = root_cert
ef.issuer_certificate = root_cert
root_cert.add_extension(ef.create_extension("subjectKeyIdentifier", "hash", 
false))
root_cert.add_extension(ef.create_extension("basicConstraints", "CA:TRUE", 
true))
root_cert.add_extension(ef.create_extension("keyUsage","digitalSignature, 
keyCertSign, cRLSign", true))
root_cert.sign(nodes[:root][:key], OpenSSL::Digest::SHA256.new)

puts root_cert.to_text
puts root_cert.to_pem

ca1_cert = OpenSSL::X509::Certificate.new
ca1_cert.version = 0x2
ca1_cert.serial = 0xa
ca1_cert.not_before = Time.new(2011,01,01,00,00,01)
ca1_cert.not_after =  Time.new(2020,12,31,23,59,59)
ca1_cert.subject = nodes[:ca1][:name] 
ca1_cert.issuer = root_cert.subject
ca1_cert.public_key = nodes[:ca1][:key]
ef = OpenSSL::X509::ExtensionFactory.new
ef.config = OpenSSL::Config.parse('
[polsect]
policyIdentifier = 2.5.29.32.0
CPS.1="http://beyondhypersecure.example.

Re: [openssl-users] Building 1.0.2g with

[Peter Hilton]

Jakob Bohm  writes:

> 
> In 1.0.2 and later, most of the files in ${BUILD_DIR}/include/openssl
> are supposed to be copies/symlinks to file of the same name elsewhere
> in the OpenSSL source, for instance the ones you mentions should be
> links to files in subdirectories under ${BUILD_DIR}/crypt.
> 
> However in your case, I suspect the following sequence of events:
> 
> 1. configure or make depend sees that you have disabled some ciphers
>and don't link header files for those ciphers.
> 
> 2. Other parts of the OpenSSL source code blindly include those header
>files because they used to be present in ${BUILD_DIR}/include/openssl
>even when disabled, omitting them only (if at all) in the installed
>files under ${INSTALL_DIR}/include/openssl
> 
> If this theory holds, this would be a bug in the 1.0.2 tree, either
> in the build scripts or in the source files that include headers for
> disabled ciphers, whichever fix creates the smallest/simplest patch
> should be applied.
> 
>

Hi,
   I am seeing the same problem with 0.9.8zh.
config with no-idea and the symlink to the idea.h header file is
not created.  This breaks the compile in multiple places in crypto.
make depend does not create the link when no-idea is configured.

We are building openssl inside a customised build environment so I simply
create the symlink after config is run and prior to running the compile.

Just my pennies worth

cheers
pete

pete hilton
also at:-
 saru...@ruvolo-hilton.org
 



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

Re: [openssl-users] Converting DER encoded unsigned CSR to internal OpenSSL format

[Peter P.]

Hi Wim,

I'll give this a shot, thank you for the suggestion!

-Peter

On Wed, Nov 11, 2015 at 5:05 PM, Wim Lewis <w...@omnigroup.com> wrote:

>
> On Nov 9, 2015, at 3:46 PM, Peter P. <p.pan48...@gmail.com> wrote:
> > I'm writing an application using Openssl 1.0.2d where I am trying to
> take a DER encoded unsigned CSR and read it into an X509_REQ data structure
> via the d2i_X509_REQ_bio() function. This function errors out during when I
> attempt to read in my unsigned CSR and I would like to know if there is any
> other way to read in an unsigned CSR into an X509_REQ data structure.
>
> A CSR (from PKCS#10 / RFC2986) has the structure:
>
>SEQUENCE { CertificationRequestInfo, AlgorithmIdentifier, BIT STRING }
>
> where the actual request is the CertificationRequestInfo, and the
> signature is composed of the AlgorithmIdentifier + BIT STRING.
>
> Are you trying to just read in a bare CertificationRequestInfo structure?
> I suspect you can do that with a call like
>
> ASN1_item_d2i_bio(ASN1_ITEM_rptr(X509_REQ_INFO), bp, req)
>
> which is the same as the body of d2i_X509_REQ_bio(), but with X509_REQ
> replaced by X509_REQ_INFO. I haven't tried it, though.
>
> (Whether it's a *good idea* to pass bare CSR info structs around is
> another question but I'll leave that up to you.)
>
>
> Wim.
>
> ___
> 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] Converting DER encoded unsigned CSR to internal OpenSSL format

[Peter P.]

Hi Dr. Henson,

Thank you for your reply. To work around this issue in my application, I
have considered attempting to re-sign an already signed CSR. Is this
possible with OpenSSL?

Thank you again,

Peter

On Tue, Nov 10, 2015 at 9:18 AM, Dr. Stephen Henson <st...@openssl.org>
wrote:

> On Mon, Nov 09, 2015, Peter P. wrote:
>
> > Hi,
> > I'm writing an application using Openssl 1.0.2d where I am trying to
> take a
> > DER encoded unsigned CSR and read it into an X509_REQ data structure via
> > the d2i_X509_REQ_bio() function. This function errors out during when I
> > attempt to read in my unsigned CSR and I would like to know if there is
> any
> > other way to read in an unsigned CSR into an X509_REQ data structure.
> >
>
> The signature on a CSR is mandatory so if it is not present it isn't a
> valid
> CSR structure any more: that will cause the parser to reject it.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> ___
> 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] Converting DER encoded unsigned CSR to internal OpenSSL format

[Peter P.]

Hi,
I'm writing an application using Openssl 1.0.2d where I am trying to take a
DER encoded unsigned CSR and read it into an X509_REQ data structure via
the d2i_X509_REQ_bio() function. This function errors out during when I
attempt to read in my unsigned CSR and I would like to know if there is any
other way to read in an unsigned CSR into an X509_REQ data structure.

Thank you,

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

[openssl-users] READ error during tape restore via OpenSSL on AIX

[Klee, Peter (King of Prussia)]

Hello OpenSSL community,


We are running OpenSSL on IBM AIX version 7.1 on an IBM Power8 server.   The 
OpenSSL versions installed are as follows:

  openssh.base.client
   6.0.0.6103   COMMIT   COMPLETE 06/25/14 17:46:58

  openssh.base.server
   6.0.0.6103   COMMIT   COMPLETE 06/25/14 17:46:58

  openssl.base
1.0.1.510   COMMIT   COMPLETE 09/23/14 15:49:29

When backing up files to tape with no encryption using the AIX backup command, 
we are able to restore the files from tape using the AIX restore command, with 
no issue.

When backing up files to tape with symmetric OpenSSL encryption (for instance 
blowfish, aes-128-cbc, aes-256-cbc, with either a password or a key file) the 
files back up to tape without error.  But when restored from tape, we 
consistently receive the following error messages during the restore:

804401144:error:0200B005:system library:fread:I/O error:bss_file.c:245:
804401144:error:20082002:BIO routines:FILE_READ:system lib:bss_file.c:246:
One of the files backed up and restored is a database file (Intersystems Cache) 
and the restored database passes an integrity check after each restore.  The 
restored text files in the target directory come up with no differences when 
using diff to compare them to the original files in the source directory.  So, 
we aren't seeing any issues with the integrity of the restored files.

But why are the two error messages showing up consistently?

Here's our backup command, this time using the aes-256-cbc encryption algorithm 
and the password shown:

find . -print | backup -ivUf - | openssl enc -aes-256-cbc -k abc123 -out 
/dev/rmt0.1
And here's the restore command and the result:
openssl enc -d -aes-256-cbc -k abc123 -in /dev/rmt0.1 | restore -xvqf -
IBM8_SYS2(/store/abcalt)$ bc -k abc123 -in /dev/rmt0.1 | restore -xvqf - 
x0 .
x974127104 ./CACHE.DAT
804401144:error:0200B005:system library:fread:I/O error:bss_file.c:245:
804401144:error:20082002:BIO routines:FILE_READ:system lib:bss_file.c:246:
x40904 ./RMS
x0 ./stream
IBM8_SYS2(/store/abcalt)$


Those two exact 804401144 error messages show up consistently during every tape 
restore.  We have tried specifying the block size on the backup and restore but 
it makes no difference.  It should be noted that when we use the backup and 
restore commands with OpenSSL encryption and no tape drive, but backing up to a 
different directory and restoring from there, there are no errors during the 
restore.  The errors only happen when restoring from tape.

Any thoughts you have on this are appreciated.


Peter M Klee
System Analyst
Fiserv DataSafe
Fiserv Credit Union Solutions
800-523-7282 x 2376

___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

[openssl-users] Remove Anchor

[Peter Fraser]

Hi All
Please let me know if I am posting to the correct list. I set up a reverse
proxy for my website using nginx and I had to export the certificate from
my web server to put on the proxy. On windows I exported the certs to a
.pfx file. On my Unix box, I used the command below to export all the certs
to a file. Then I manually removed the private key.

*openssl pkcs12 -in file_name.pfx -out outputfile.txt –nodes*


Afterwards when I ran a test against it using ssllabs it said that my cert
contained an anchor. Does anyone know how to remove this anchor and leave
only the necessary certs for my proxy to use?


Regards
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: [SPAM?] Re : 2 Server certificates

[Peter Sylvester]

https://www.openssl.org/docs/ssl/SSL_load_client_CA_file.html

Load names of CAs from file and use it as a client CA list:

 SSL_CTX *ctx;
 STACK_OF(X509_NAME) *cert_names;

 ...
 cert_names = SSL_load_client_CA_file(/path/to/CAfile.pem);
 if (cert_names != NULL)
   SSL_CTX_set_client_CA_list(ctx, cert_names);
 else
   error_handling();


The PKI used for a server certificate is not the same as the one used for 
client certficates.

- a server has a certificate (issued by whatever PKI)
- a server can request that a client presents a certificate
  in order to do so, the protocol requires to send a list
  of issuers (of client certificats). There is no relation
  between  client certs and the server cert.



On 06/13/2014 12:15 PM, nicolas@free.fr wrote:

Hi,

the fact is a server can only send a single certificate, however this one can 
be signed by multiple CAs
on the other side, a client have (in general) a list of trusted CAs, not a 
single one

so there are two options :
- either each client knows the two CAs, then the server can send a certificate 
signed by any of them
- or each client knows only about its own CA, then the server must send a 
certificate signed by both CAs
(note that this is symmetrical, the server verify client certificate the same 
way)

I've never heard about a server with multiple certificates, at least not with 
SSL/TLS protocols...


concerning the list of trusted CAs sent by the server to the client, it comes 
from the fact that a client can have multiple certificates, for different 
servers that can use their own CA
so it allows a client to choose the good certificate to send to a specific 
server

concerning the server, if it's in public access it uses a certificate issued by a 
well-known CA (for example one included in your browser)
if it's private, it can use its own CA or even a self-signed certificate, and 
the client has to recover the trusted certificates by itself (this happens the first time 
you connect to a SSH server for which you have no certificate, or on some websites)


hope I made it clear
good luck!


- Mail d'origine -
De: Hafedh TRIMECHE hafedh.trime...@gmail.com
À: openssl-users@openssl.org
Envoyé: Fri, 13 Jun 2014 10:22:46 +0200 (CEST)
Objet: Re: Re : Re: Re : Re: 2 Server certificates

Hi Nicolas,

pit-ca issued another certificate to a client wanting to connect to the same
server identified by secure.payerspot.com.

I'm looking for a solution allowing two clients to connect to the same
server using certificates issued by different CAs.

In this case the client forces the server verification by requesting its
certificate.

So the two server certificates must be sent to each client .

Cetificate chain1 (issued by CA1)
0 s:
i:
BEGIN CERTIFICATE-
-END CERTIFICATE-

Cetificate chain2 (issued by CA2)
0 s:
i:
BEGIN CERTIFICATE-
-END CERTIFICATE-

Can two certificates be presented to a client which will identify the
chained certificate to be verified ?

Regards.




--
View this message in context: 
http://openssl.6102.n7.nabble.com/2-Server-certificates-tp50872p50937.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Upgrade Breakage of Perl Script: RH recent

[Peter Abbott]

Thanks Dave,

I have approached the server operator about the security shortcomings that
you pointed out. In the interim I used your suggestion and altered the
cipher list to  SSL_cipher_list DEFAULT:!ECDH.

This has sorted the problem. I am very grateful for your assistance.

Peter.


On 21 December 2013 08:08, Dave Thompson dthomp...@prinpay.com wrote:

 I don’t use Fedora and track its versions, but assuming those are recent

 RedHat including Fedora recently enabled ECC in its openssl packages

 after years of excluding it over concerns about Certicom’s patent.

 That increases the number of cipher suites in the Client Hello message

 and also adds two extensions (although fairly small for RH) which makes

 the Hello message bigger, and some servers are known to hang or otherwise

 fail when the Hello message is bigger than used to be “normal” a decade
 ago.

 Apparently api.tab.com.au:443 is such; tested with s_client  255 hangs.

 (In a 404 it claims to be “WebLogic Server”, which I don’t know about.)



 I also observe this server does not implement 5746 (secure renegotiation)

 and will negotiate only TLSv1(.0) and 4 akRSA suites (RC4, 3DES, both AES)

 suggesting it is rather old. If you can’t get the server operator(s) to
 fix their

 server, you need to get openssl as used by perl to send a shorter
 ClientHello.

 The most straightforward way is to reduce the set of suites offered,

 especially since the server implements only 4.



 According to perldoc for the best perl I have (5.6.1 ActivePerl for
 Windows)

 but not tested, LWP::UserAgent can take a hash ssl_opts which apparently
 are

 passed (eventually) to openssl. Just making SSL_cipher_list DEFAULT:!ECDH

 should reduce the cipher list enough, although you might want even more

 restrictive settings for other reasons, like in general you should always

 prohibit “export” and “LOW” ciphers which have been broken for years.

 Alternatively it looks like you can set SSL_version to exclude TLSv12 or
 just

 force TLSv1; that excludes a bunch of ciphers and also the sigalgs
 extension,

 which should make Hello short enough.







 *From:* owner-openssl-us...@openssl.org [mailto:
 owner-openssl-us...@openssl.org] *On Behalf Of *Peter Abbott
 *Sent:* Thursday, December 19, 2013 17:29
 *To:* openssl-users@openssl.org
 *Subject:* *** Spam *** Upgrade Breakage of Perl Script



 Hi,



 I have a simple perl script which supplies a username and account password
 to a server. The server in turn returns a password token for further
 operations. The script does not specifically use openssl but the perl
 modules LWP::UserAgent and or HTTP::Request must do. The script worked
 perfectly up to openssl version 1.0.1e-4.fc19.x86_64. Further upgrades to
 1.0.1e-28.fc19 and 1.0.1e30.fc19 just hang somewhere at the handshake stage.



 I am only a novice and have a limited understanding of what is going on.
 Part of the script is as follows:



 #!/usr/bin/perl -w



 use strict;

 use LWP::UserAgent;

 use HTTP::Request;



 my $message = '?xml version=1.0 encoding=utf-8?

 soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
 xmlns:ser=http://service.thirdparty.api.neo.tabcorp.com.au/;

   soapenv:Header/

   soapenv:Body

   ser:authenticateAccount

   apiMeta

   deviceId111/deviceId


 jurisdictionId2/jurisdictionId


 requestChannel1/requestChannel


 usernamePasswordToken/usernamePasswordToken

   /apiMeta

   authRequest

   accountIdxx/accountId


 accountPassword/accountPassword

   /authRequest

   /ser:authenticateAccount

   /soapenv:Body

 /soapenv:Envelope';



 my $keyn;

 my $userAgent = LWP::UserAgent-new();

 my $request = HTTP::Request-new(POST = '
 https://api.tab.com.au/tabapi/services/thirdPartyAuthenticate');

 $request-header(SOAPAction = '
 http://service.thirdparty.api.neo.tabcorp.com.au/;');

 $request-content($message);

 $request-content_type(text/xml; charset=utf-8);

 my $response = $userAgent-request($request);

 if($response-code == 200) {

   print $response-as_string;

 }

 else {

   print zs

 }





 Can anyone shed some light on what is happening here or what I can do to
 remedy the problem?



 Thanks,

 Peter.

Upgrade Breakage of Perl Script

[Peter Abbott]

Hi,

I have a simple perl script which supplies a username and account password
to a server. The server in turn returns a password token for further
operations. The script does not specifically use openssl but the perl
modules LWP::UserAgent and or HTTP::Request must do. The script worked
perfectly up to openssl version 1.0.1e-4.fc19.x86_64. Further upgrades to
1.0.1e-28.fc19 and 1.0.1e30.fc19 just hang somewhere at the handshake stage.

I am only a novice and have a limited understanding of what is going on.
Part of the script is as follows:

#!/usr/bin/perl -w

use strict;
use LWP::UserAgent;
use HTTP::Request;

my $message = '?xml version=1.0 encoding=utf-8?
soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:ser=http://service.thirdparty.api.neo.tabcorp.com.au/;
soapenv:Header/
soapenv:Body
ser:authenticateAccount
apiMeta
deviceId111/deviceId
jurisdictionId2/jurisdictionId
requestChannel1/requestChannel
usernamePasswordToken/usernamePasswordToken
/apiMeta
authRequest
accountIdxx/accountId
accountPassword/accountPassword
/authRequest
/ser:authenticateAccount
/soapenv:Body
/soapenv:Envelope';

my $keyn;
my $userAgent = LWP::UserAgent-new();
my $request = HTTP::Request-new(POST = '
https://api.tab.com.au/tabapi/services/thirdPartyAuthenticate');
$request-header(SOAPAction = '
http://service.thirdparty.api.neo.tabcorp.com.au/;');
$request-content($message);
$request-content_type(text/xml; charset=utf-8);
my $response = $userAgent-request($request);
if($response-code == 200) {
print $response-as_string;
}
else {
print zs
}


Can anyone shed some light on what is happening here or what I can do to
remedy the problem?

Thanks,
Peter.

Re: Certificate extensions

[Peter Sylvester]

On 09/18/2013 09:53 AM, Eisenacher, Patrick wrote:

-Please also note that adding extensions to a certificate request usually 
doesn't make any sense, as those get added to the certificate solely by the 
certificate issuer's grace.



hi,

I seem to disagree, well, usually saves you :-)

Setting your email address or a server name into the subjectaltname, how do you 
do this otherwise?
setting commonname for the server, ok, setting an email attribute that will them
be copied by the CA (and the email removed because it is depracated)?

Setting ALL extensions makes a lot of sense, IMO a CA should not add and modify 
thngs, a CA
should *validate* them. The requester indicates what should be in the cert.

The current practice by some registrars to add example.org as another name when
you have ordered www.example.com etc may be nice for some people, but annoying
for others, at best a surprise when policy and practice documents do not even 
mention
these behaviours.

Peter Sylvester
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: CA hierarchy / pathlen:0

[Peter Sylvester]

On 08/22/2013 01:29 PM, Peter1234 wrote:

Hi Walter,

I started with release 0.9.8h and just updated to release 1.0.1e (both on MS
Windows). The update to release 1.0.1e didn't change anything unless that
the new release does not redirect certificates converted from PEM format to
text format into specified file:

openssl x509 -in Root_Key_SCert.pem -out Root_Key_SCert.txt -text (text is

displayed on screen but not redirected to file, worked with release 0.9.8h)

Peter



Verification of pathlen is for relying parties.

If you own the key of a CA (the quotes are intended), you can
sign whatever structure you want. Openssl just uses a ca certficate
as a helper to avoid copying its name and some other things.

You can use the raw asn1 encoder to create very funny things.
No control, nothing, it works as intended.




__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Verify callback and sending of the client certificate

[Peter Sylvester]

On 08/09/2013 11:17 AM, Florian Weimer wrote:

Qt installs a verification callback like this

|// Register a custom callback to get all verification errors.
|X509_STORE_set_verify_cb_func(ctx-cert_store, q_X509Callback);

It is not recommended to access to members in the way above, but rather:

X509_STORE_set_verify_cb_func(SSL_CTX_get_store(ctx), q_X509Callback);

/P
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Question about intermediate certificate chain

[Peter Sandelin]

Please note that s_client is used for debugging connections not certs
and might connect EVEN IF the server certificate is not good.

http://www.openssl.org/docs/apps/s_client.html#item__verify
Currently the verify operation continues after errors so all the
problems with a certificate chain can be seen. As a side effect the
connection will never fail due to a server certificate verify
failure.

For checking your certificate chains I recommend OpenSSL's verify command.
http://www.openssl.org/docs/apps/verify.html

P

On 22 May 2013 03:06, Somesh Chakrabarti itsmesom...@gmail.com wrote:
 In your s_client command, you still need to include the -CAfile parameter
 and point it to just the self-signed Root certificate. Your server is
 sending the intermediates but the client is not able to verify the chain up
 to a Root.

 You may want to edit cacerts.pem to include only the Root certificate and
 try again.


 On Tue, May 21, 2013 at 5:50 PM, Jorge Ventura
 jorge.araujo.vent...@gmail.com wrote:

 That is what I have when I don't include the intermediate in the command:

 openssl s_client -connect 10.10.10.10:443 -verify 5 -state -showcerts
 verify depth is 5
 CONNECTED(0003)
 SSL_connect:before/connect initialization
 SSL_connect:SSLv2/v3 write client hello A
 SSL_connect:SSLv3 read server hello A
 depth=0
 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
 Lake/O=ACME, INC/CN=www.acme.com
 verify error:num=20:unable to get local issuer certificate
 verify return:1
 depth=0
 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
 Lake/O=ACME, INC/CN=www.acme.com
 verify error:num=27:certificate not trusted
 verify return:1
 depth=0
 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
 Lake/O=ACME, INC/CN=www.acme.com
 verify error:num=21:unable to verify the first certificate
 verify return:1

 And this one when I include the two intermediate at cacerts.pem.

 openssl s_client -connect 10.10.10.10:443 -verify 5 -CAfile
 cacerts.pem -showcerts
 verify depth is 5
 CONNECTED(0003)
 depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
 verify return:1
 depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 verify return:1
 depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
 verify return:1
 depth=0
 /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
 Lake/O=ACME, INC/CN=www.acme.com
 verify return:1
 ---
 Certificate chain
  0
 s:/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior
 Lake/O=ACME, INC/CN=www.acme.com
i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA



 On Tue, May 21, 2013 at 7:26 PM, Wim Lewis w...@omnigroup.com wrote:
 
  On 21 May 2013, at 5:02 PM, Jorge Ventura wrote:
  Because the client trust the connection when I inform the
  intermediate, I suppose the server is not sending the intermediate,
  only the first certificate in the chain and in this case the command
  fail.
 
  That is a reasonable conclusion. You can check for sure using the
  -showcerts option to openssl s_client.
 
 
  __
  OpenSSL Project http://www.openssl.org
  User Support Mailing Listopenssl-users@openssl.org
  Automated List Manager   majord...@openssl.org
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Cipher sorting: ssl_cipher_apply_rule never processes list with one member?

[Peter Sandelin]

Hi,
while debugging another thing I discovered what I think is a bug in
the CIPHER list handling.
Can someone please confirm or disprove that this is a bug?

OpenSSL version 1.0.1c.

In function  ssl_cipher_apply_rule the break criteria (curr == last)
is strange.
I arrive here with only ONE member in my list, so head == tail.
ssl_ciph.c: 956

954:   for (;;)
955:   {
956: if ((curr == NULL) || (curr == last)) break;


If it breaks on (curr == last),
then a list with only one member will not be processed at all.

I think the check
if (curr == last) break;
should be in the end of the for -loop instead?

best regards
Peter
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: openssl s_server client verification

[Peter Sandelin]

On 22 March 2013 00:19, barcaroller barcarol...@gmail.com wrote:

 When the openssl s_server program is unable to verify a client
certificate, it prints out the following error message:

verify error:num=21:unable to verify the first certificate
verify return:1

 but then continues running as if nothing happened.  Shouldn't the program
stop immediately?

It is a intentional feature.
But I think the s_server's documentation is missing an important thing
mentioned for s_client.

http://www.openssl.org/docs/apps/s_client.html#item__verify
-verify depth

The verify depth to use. This specifies the maximum length of the server
certificate chain and turns on server certificate verification. Currently
the verify operation continues after errors so all the problems with a
certificate chain can be seen. *As a side effect the connection will never
fail due to a server certificate verify failure*.


P

Re: 0.9.8 vs 1.0.x

[Peter Beal]

We've found that upstream-tracker.org was a good place to start. 
Unfortunately, it only performs comparisons from one release to the 
next, so what we did was download one of the tools that makes up 
upstream-tracker and ran it against the specific release we were using 
and the release to which we were intending to upgrade to. This provides 
a report of the symbols that have changed in the public API to the 
library, which is just a detailed starting point.


Pete

On 3/26/13 3:44 PM, Jakob Bohm wrote:

You can also read the detailed list in the file CHANGES in the OpenSSL
source code download, that file lists the changes, version by version
going back several versions.  However the file in the latest 1.0.x 
archive
does not list which fixes were made to 0.9.8 after work started on 
version

1.0.0, so you should get both the latest 0.9.8 source download and the
latest 1.0.x source download and compare the CHANGES files from both.

Hopefully all the stuff that was fixed in later 0.9.8 releases was also
fixed in various 1.0.x releases around the same dates, since this is the
normal procedure of the project.

Programs compiled against 0.9.8 headers will need to be recompiled before
linking with 1.0.1 libraries or using them with 1.0.1 DLLs.  This applies
whenever any of the digits in the version number changes, but usually not
if only the extra letter is changed e.g. from 1.0.1d to 1.0.1e .

On 26-03-2013 20:15, Walter H. wrote:

the major features that 1.0.x supports are

openssl ts (http://www.openssl.org/docs/apps/ts.html)
openssl cms (http://www.openssl.org/docs/apps/cms.html)

On 26.03.2013 18:50, Gopakumar Pillai wrote:


Hi,

Can any one point me to a location where I can find the major 
differences between versions 0.9.8 and 1.0.x?


Now that 0.9.8 may not live for long, planning to move to 1.0.x 
versions.


Are they API compatible? Any other restrictions?

Thank You in advance.

--Gopu





__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: possible Bug in OpenSSL - rfc 3161 - TSA service

[Peter Sylvester]

for those who don't read openssl-dev


 Original Message 
Subject:[openssl.org #3016] openssl ts fix
Date:   Wed, 13 Mar 2013 16:13:31 +0100
From:   Peter Sylvester via RT r...@openssl.org
Reply-To:   openssl-...@openssl.org
CC: openssl-...@openssl.org



Hi,

I have weakend the Esscertid logic a bit. Only the signer certficate is
checked and it must be in the first Esscertid.

This resolves issues when TSAs add attribute certs etc.
Since RFC 3161 does not require a client to check anything
else than the presence of the signer cert (and even is is badly written),
I think the verification of a chain in the ess was not appropriate
logic.

regards

Re: possible Bug in OpenSSL - rfc 3161 - TSA service

[Peter Sylvester]

On 03/11/2013 11:17 PM, kap...@mizera.cz wrote:

That is what we talk about here.
Try to check previous posts in this thread.


rfc 3126 tells

 This document mandates the presence of this attribute as a signed CMS
   attribute, and the sequence must not be empty.  The certificate used
   to verify the signature must be identified in the sequence, the
   Signature Validation Policy may mandate other certificate references
   to be present, that may include all the certificates up to the point
   of trust.  The encoding of the ESSCertID for this certificate must
   include the issuerSerial field.

RFC 5035 says

  If more than one certificate is present, subsequent certificates
  limit the set of certificates that are used during validation.
  Certificates can be either attribute certificates (limiting
  authorizations) or public key certificates (limiting path
  validation).  The issuerSerial field (in the ESSCertIDv2
  structure) SHOULD be present for these certificates, unless the
  client who is validating the signature is expected to have easy
  access to all the certificates required for validation.  If only
  the signing certificate is present in the sequence, there are no
  restrictions on the set of certificates used in validating the
  signature.

The time stamp does not include issuerSerial in the second esscertid.

There is no specification of any profile of time stamps that
indicates that a client MUST support attribute certs.

I do not think that the authors of 3161, 3126 has in mind any
support of attribute certs. I don't recall any profile requiring
this.

if a timestamp ess would be ok with an attribute cert, what is
the client supposed to do? It can verify the signatures of
the attribute cert up to some trust anchor, but then?
what authorisation is supposed to be checked? that the
tsa is allowed to issue certs for a particular policy? (don't
yes, maybe).

if the TSKlient is able to do something non stadardized special
verification, use that one.

Peter






__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: possible Bug in OpenSSL - rfc 3161 - TSA service

[Peter Sylvester]

On 03/12/2013 09:30 AM, kap...@mizera.cz wrote:





RFC 3161 is written badly.  The whole text was a joke anyway.

   The requester SHALL verify that the
   TimeStampToken contains the correct certificate identifier of the TSA

One may conclude that openssl should simply not validate anything else than
the first certificate. And simply ignore the rest of the ESS sequence.
Probably with an option.
 



It must not be there, if the attribute cert is available. If the TSQ is with -cert = the TAC 
certificate is included in TSR. (I know - it is not in our example which is nocert).

Is there anywhere in the policy of the TSA an indication about what a
client is supposed to do with the atribute certificate, i.e. where
is the documentation of the behaviour of their own client.
There are two OID as attributes. .


That is what about I fight with the Certification Authority.
I was (I am) afraid if their timestamps are rfc 3161 compliant or not.
They claim YES.

What do you thing ?

You can add critical extensions into the signing cert, whatever you want,
you remain conformant but not interoperable.


I'm not sure - on one side you are right: authors of 3161, 3126 has in mind any  support of 
attribute certs


but on the other side: rfc 3161 simply refers to RFC 2634 where are attr. certs mentioned = they 
may (can) be there and should not preclude verification process = the client MUST be able 
understand all what is in tree with 3161 as root.

That's because the authors of RFC 3161 had probably overlooked the
possibility of attribute certs. T
he only reason for using ESSCert was to include a reference
to the signing cert (and maybe its chain), but not to allow all options.

Although the text says (last sentence):

If the certReq field is present and set to true, the TSA's public key
   certificate that is referenced by the ESSCertID identifier inside a
   SigningCertificate attribute in the response MUST be provided by the
   TSA in the certificates field from the SignedData structure in that
   response.  That field may also contain other certificates.

I do not think that the last sentence means attribute certificates.
In fact RFC 3161 doesn't tell what one has to verify, And, as said
in the beginning, there is nothing in the text that says that
a client has to verify anything beyong the TSA's signature cert.

   However, the actual identification of the entity
   that signed the response will always occur through the use of the
   certificate identifier (ESSCertID Attribute) inside a
   SigningCertificate attribute which is part of the signerInfo (See
   Section 5 of [ESS]).

Here one talks about IDENTIFICATION, attribute certs are for something else.


BTW: rfc 3126, 5035, ... are not referred by 3161 = in timestamps may be used only and only what 
is in tree with 3161 as root.

= rfc 3126, 5035 are not valid for timestamps.



if a timestamp ess would be ok with an attribute cert, what is
the client supposed to do? It can verify the signatures of
the attribute cert up to some trust anchor, but then?
what authorisation is supposed to be checked? that the
tsa is allowed to issue certs for a particular policy? (don't
yes, maybe).

if the TSKlient is able to do something non stadardized special
verification, use that one.


That is no solution - the Q is: are or are not these timestamps compliant with 
RFC 3161.

Compliant is not the right word, conformant. And since there
are no real conformance requirements, the question is almost
useless. You may try to use the argument, that the TSA MUST
include teh TSA cert into the ESScertid and add and nothing else
but that won't word because this argument is French. ;-)

The ESS cert that there SHOULD be a issuer and serial. That's not the
case.



If not, then they have no value.




Remark: discussed CA (TSA) is official, one of main CA in our country - whole government things, 
law (electronic sigs, timestamps, ..), ... depends on such institution. So it is very important Q.

The question is interoperability.

As said, I think the openssl tests can simply be weakend to only validate the
first ESS cert.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: possible Bug in OpenSSL - rfc 3161 - TSA service

[Peter Sylvester]

On 03/11/2013 06:43 PM, kap...@mizera.cz wrote:

Hello,



...


As I know, the attr. certs are not very necessary = that is why I mean, that temporary solution 
would be to ignore them in verification process. At least in TS it would solve the problem.


Just for info:  converting te stuff to pkcs7 and verifying with smime works 
fine.




--kapetr


__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: possible Bug in OpenSSL - rfc 3161 - TSA service

[Peter Sylvester]

the second ess certid says

SEQUENCE {
   OCTET STRING
52 EE 29 A7 35 03 04 F8 94 21 48 72 76 9F 24 78
   EB 6C D7 AC
}

by 3721926ea67e877df5f4e35dd3c87397eef33d4f
is the hash of the der version of te intermediate cert.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: possible Bug in OpenSSL - rfc 3161 - TSA service

[Peter Sylvester]

On 03/11/2013 08:01 PM, kap...@mizera.cz wrote:

Of course YES.
Timestamp reply is nothing else as CMS SignedData structure.


not quite but ts -reply -tokenout converts it to such a thing

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: possible Bug in OpenSSL - rfc 3161 - TSA service

[Peter Sylvester]

On 03/11/2013 10:31 PM, kap...@mizera.cz wrote:


Dne 11.3.2013 21:42, Peter Sylvester napsal(a):

the second ess certid says

SEQUENCE {
OCTET STRING
 52 EE 29 A7 35 03 04 F8 94 21 48 72 76 9F 24 78
EB 6C D7 AC
 }

by 3721926ea67e877df5f4e35dd3c87397eef33d4f
is the hash of the der version of te intermediate cert.



it is the sha1 hash itself and it is NOT hash of any cert in verification chain.

openssl ts does not support attribute certs AFAIR


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: is openssl supports TLSv1.2

[Peter Sand]

Yes, OpenSSL since *1.0.1* supports TLS1.2

http://www.openssl.org/news/news.html

*Major changes between OpenSSL 1.0.0h and OpenSSL 1.0.1:

...*

* Support TLS v1.2 and TLS v1.1.
*
*
Look here for more overview.
**http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations#Protocol_Support*
http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations#Protocol_Support


BR
Peter



2013/3/7 Arashad Ahamad araha...@in.ibm.com

 Hi,

 is there any idea that openssl support TLSv1.2?



 Regards
 Arashad Ahamad


  *Arashad Ahamad/India/IBM*

 02/28/2013 04:37 PM
   To
 openssl-users@openssl.org
 cc
   Subject
 is openssl supports TLSv1.2



 Hi ,

 I have gone through the change log of openssl implementation and
 come to know that there is initial support for TLSv1.2 in the openssl
 library.

 Can you please conform that latest version of openssl is
 compliance with TLSv1.2?


 Please let me know as soon as possible.



 Regards
 Arashad Ahamad

Re: [openssl-users] Is ordering of distinguished names for subject and issuer in OpenSSl 0.9.8 certificates important?

[Peter Sylvester]

Ording is important. unfortunately the default order shown in the textual
form is not the same as for ldap tools. using openssl asn1parse shows
the encoding, country code should come first.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to tell when no more progress can be made

[Peter Sylvester]

On 01/17/2013 12:10 PM, A G wrote:

Hi
Here
http://marc.info/?l=openssl-usersm=124386218929227
It states that

...This is why it is very important to understand that any possible forward 
progress on any port (and a write operation that returns WANT_READ may have made forward 
progress!) requires you to retry all pending operations on all ports

So am I correct in understanding that an SSL_read() that returned WANT_READ may 
have made forward progress (even if it did not return any data)?

I have an event driven single threaded app that has 3 non blocking ssl sockets. 
When each socket completes its connection, I have the sockets read until I get 
a WANT_READ. My understanding is that a WANT_READ means I may now invoke 
select() and wait until the socket is ready for reading again.

you may also receive WANT_WRITE or WANT_READ when you ssl_write.

as long as you do not have interrupted ALL, you do not need to select,
after a successful operation you can retry the others, or do
a select to determine which are actually ready.

a select call is only to avoid a cpu intensive loop on the ssl_read/write 
operations.




__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: extensions in certifications

[Peter Sylvester]

On 12/11/2012 09:45 PM, Michael Mueller wrote:

Could I get a nudge. I'd like to get the SANs to show up in my certs.

in my request:

Requested Extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Subject Alternative Name:
DNS:ossvirt4, DNS:gws001

these are not dns names. you should review what your client
hosts have as a default domain, etc. It is not obvious whether
browsers will accept this

regarding the hint (and solution) about copying the extension,
you should check what you receive as a cert request, e.g.
whether someone wants a CA cert for example.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to over-ride SSL_CTX_use_PrivateKey_file() behavior with custom engine

[Peter Sylvester]

On 12/07/2012 11:05 AM, LN wrote:


 I have a feeling it does so because I tried to save that  returned
 EVP_PKEY to a PEM file with PEM_write_bio_PrivateKey and then to load it
 back from the same file with PEM_read_bio_PrivateKey.
 Saving worked, but loading failed (with some decoding error inside
 openss). The length of the base64 string in the PEM file for the key was
 very small in comparision with what is usually the length for private keys.





Often, at least for other HSM, a private key returned does not contain the real 
p and q
values but just some index to enumerate a key in the hsm. These are normally 
some
small numbers and not big primes.

you might see this if you do openssl rsa -text yourfile

Re: This is one for the Pros: cert is not privkey

[Peter Parker]

Dave,
Thank you for the quick and thorough response. This is good stuff.

Yes, so the files I will be encrypting will be over 100 bytes. I am aware
of the key size requirements - 1028 was only used as a placeholder for the
example commands I provided. Does this mean that I will be able to use RSA
or not?

You lost me with the chaining and AKI stuff. I have no idea what either of
those mean. Does the CMS approach that you suggested address this issue? In
either case, I like the idea of using CMS.

The major reason that I am using the x509 (or originally the ca) utility is
that I want to be able to set begin and end valid dates (-startdate,
-enddate**) for the public and private keys and create certificates as
well. I also want to associate some metadata with them like organization
and locality, for that I am currently using the -subj command.

Am I correct that the large PEM file includes both a public and private
key? If so I should be able to extract them from the PEM and then use
something (rsautl, enc or ...) to encrypt and decrypt the files. After
successfully extracting what I understand to be a public key from the PEM,
I receive this error from the rsautl utility: unable to load Public Key.
Error in rsautl

Could you give me some examples of how you would use CMS or, just use these
utilities properly, to achieve what I'm trying to do.

I really appreciate your help.

Thanks,
Peter

On Tue, Nov 20, 2012 at 10:17 PM, Dave Thompson dthomp...@prinpay.comwrote:

 From: owner-openssl-us...@openssl.org On Behalf Of Peter Parker
 Sent: Tuesday, 20 November, 2012 20:59

 Subject: This is one for the Pros

 Not really. This is pretty basic.

 I've been trying to generate a public/private key pair after
 generating the certificates, but OpenSSL keeps giving me an error.
 The commands and the error are below. Thanks.

 No you're not; you're generating a CA keypair and cert (directly),
 then an application keypair, then an application cert (via CSR).
 Which is the (well, a) correct sequence, for one entity.

 Commands
 #openssl req -new -x509 -extensions v3_ca -days 365 -keyout caKey.pem
 -passout pass:test -out caCert.crt -batch
 #openssl genrsa -out application.pem -passout pass:test -des3 1028

 1028 is an unusual size for an RSA key; most folks use power-of-2
 based values like 1024 1536 2048. 1024 is presently rather marginal
 for security; for example, NIST has it deprecated since the end of
 2010, and prohibited after the end of 2013, for US government use.

 #openssl req -new -key application.pem -passin pass:test -out
 application.csr -batch

 A second req -new -batch generates a CSR with the same DN ...

 #openssl x509 -req -days 365 -in application.csr -CA caCert.crt
 -CAcreateserial
 -CAkey caKey.pem -passin:test -out test-key.pem -extensions ssl_cert

 ... thus this creates a CA-signed cert which appears to be self-signed,
 and will not chain correctly with OpenSSL. If the ssl_cert section of your
 config file (which doesn't exist in the distro file) includes AKI, other
 software that chains primarily by AKI may work, but this is still
 incorrect.

 This puts the cert in a file named test-key.pem, which is a misleading
 name.

 #openssl rsa -in test-key.pem -passin pass:test -out pub-key.pem -outform
 PEM -pubout

 And therefore this command, which is not the last one, fails because
 you told it to read the privatekey from a file which is a certificate.
 application.pem is your privatekey.

 #openssl rsautl -encrypt -inkey pub-key.pem -pubin -in testfile.txt -out
 eFile.ssl

 Error
 unable to load Private Key (I receive this after the last command)

 Not last.

 The key thing that I am trying to do is to encrypt some files with the key
 that I generate. I do however want to use the public and private keys that
 I get out of the PEM file using the x509 (or the ca utilities).

 If (any of) your files are larger than about 100 bytes (for 1024-bit RSA)
 you can't use raw RSA; even if they aren't, you can't interoperate with
 properly designed software that doesn't use raw RSA. The conventional
 approach is to encrypt the bulk data symmetrically with a nonce key (DEK)
 and PK (RSA) encrypt that DEK; there are numerous schemes that do this,
 but the one that OpenSSL supports directly is PKCS7/CMS/SMIME. (CMS is an
 updated Internet version of PKCS7, and SMIME is a simple wrapping of CMS.)

 You can generate and use RSA keys without using certificates (and without
 using the req x509 ca utilities) IF you have a way to distribute them
 correctly -- that is, to make sure the enveloper always uses a correct
 publickey for the recipient and not a forged, tampered, or obsolete one.
 (And similarly the verifier for a signer.) Most standard schemes do use
 X.509 certs for this purpose, because they are also standard.


 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl

Re: Find the difference in (milli|micro)seconds between two ASN1_TIME values

[Peter Sylvester]

On 11/07/2012 06:52 PM, Graham Leggett wrote:

On 07 Nov 2012, at 4:50 PM, Ted Byers r.ted.by...@gmail.com wrote:


Why does it need to be something in openssl?

Ideally because it needs to be as secure as openssl.

I'm after an accurate time duration between two ASN1_TIME values, that is not 
dependent on local conditions, or any external libraries.




try timegm in perl, or if it needs to be in C, just adopt the code
which is just a binary search using the gmtime c function.
i.e. you try to set bits to 1, convert to a textual representation
untill you find your value. You do not need to know anything
about leap years.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: MIME types for PEM encoded CRLs

[Peter Sylvester]

On 10/27/2012 02:51 PM, Graham Leggett wrote:


Section 4.1 says:

Encoding considerations: will be none for 8-bit transports and most
likely Base64 for SMTP or other 7-bit transports

What I'm after is how to interpret section 4.1 in the context of HTTP content 
negotiation.

Regards,
Graham
--


Whatever you propose as encoding in your client, you will always end up
with a der encoded file. You may try to gzip a crl as  xxx.crl.gz and do
something like the following in an apache .htaccess

files *.crl.gz
AddType application/pkix-crl .gz
AddEncoding gzip .gz
/files
RewriteEngine on
ReWriteCond %{HTTP:accept-encoding} gzip
ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.+) $1.gz [QSA,L]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Reference material on how to do certificate validation with OpenSSL

[Peter Sylvester]

The way how common names are verified in

The Most Dangerous Code in the World:
Validating SSL Certificates in Non-Browser Software

is not correct.
It gives a false match when there is more than one common name ava
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Missing entries in index.txt database - Generating CRL

[Peter Sylvester]

On 08/09/2012 12:57 PM, int0...@safe-mail.net wrote:

Hi

...


After that I generated a CRL (I own the CA) which then contained the 
certificate with the serial 0x06.

My question now is, would that be a proper workaround or is there a better 
solution? Since the CRL
only contains the serial numbers of the certificates, this seems to work 
although it is not a very good
solution.

It is a workaround if you consider the ca and crl commands as
the only officially blessed way to manage certificats,. just because it
looks convenient at first glance.

You may consider not to use the ca command at all, generate certs
using x509 instead, manage their status in whatever database you like
and, in order to create a crl using crl, you just create a temporary
file with the R entries, etc.
You may even go further and not use crl at all but create an asn.1
input for asn1parse, I leave this idea as an exercise ..

in other words, once you have understood that you only need some
file that has Rs and numbers, ... your mind should be
free to create them in any way you want.




Thanks for your help,
Martin
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: create certificate request programmatically using OpenSSL API

[Peter Sylvester]

You can take the code in apps/req.c and extract the pieces you need.



On 07/20/2012 10:17 AM, Abyss Lingvo wrote:

Hi all!

How to create certificate request programmatically via OpenSSL API?

This is the solution for command line utility:
openssl genrsa -out server_key.pem -passout pass:$passwd -des3 1024

openssl req -new -key server_key.pem -passin pass:$passwd \
-passout pass:$passwd -out server_req.pem -days 1095 \
-subj 
/C=US/ST=City/L=City/O=company/OU=SSLServers/CN=localhost/emailAddress=sslser...@company.com


How to do the same but using OpenSSL API?
Best Regards
xidex

Re: TS verify: how to fix Verify error:self signed certificate in certificate chain ?

[Peter Sylvester]

On 07/10/2012 02:38 AM, Dave Thompson wrote:

From: owner-openssl-us...@openssl.org On Behalf Of Sandro Tosi
Sent: Monday, 09 July, 2012 10:15
/usr/bin/openssl ts -verify -sha256 -untrusted CERT -CAfile
CA -data  FILE TO MARK -in TSA REPLY

and the output we get is:

140119872083624:error:2F06D064:time stamp
routines:TS_VERIFY_CERT:certificate verify
error:ts_rsp_verify.c:246:Verify error:self signed certificate in
certificate chain

We're using a Debian system, so we copied the CA into /etc/ssl/certs/
but we still see that problem: how can we fix it? is there a
way to get
a more descripting trace of the problem? Can we run manually all the
steps to verify the reply?


Your problem is not verifying the message itself, but verifying
the certificate that assures it.

removing the CA root from the CERT may help.
at least I think that CERT must not contain any self signed
cert, this is what the error message seems to suggest


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

What changed in the semantics of the openssl verify command?

[Peter Eckersley]

Here's a series of commands:

git clone https://git.eff.org/public/observatory.git
cd observatory

# get the server response for twitter.com
./scan/FasterCertificateGrabber.py twitter.com

# split it into component PEM certs
./inspect twitter.com.results
cd certs

# now try to verify it.  Note that allcerts was a poorly chosen directory
name.  It should have been allCAs...

openssl verify -untrusted twitter.com.results_2.pem -CApath ../allcerts/
twitter.com.results_1.pem

# with openssl 0.9.8*, the above command will print
# twitter.com.results_1.pem: OK
#
# but with 1.0.1c, it gives:
# twitter.com.results_1.pem: C = US, O = VeriSign, Inc., OU = VeriSign
Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)06, CN
= VeriSign Class 3 Extended Validation SSL CA
# error 20 at 1 depth lookup:unable to get local issuer certificate

-- 
Peter

Re: What changed in the semantics of the openssl verify command?

[Peter Eckersley]

Hrm, I've worked out why this was failing with 1.0.1c; the symlink for the
VeriSign Class 3 G5 root was missing from that repo's CApath.  This doesn't
entirely explain why the same exact sequence of commands verifies
successfully on a machine with openssl 0.9.8o...

On 9 July 2012 16:59, Peter Eckersley peter.eckers...@gmail.com wrote:

 Here's a series of commands:

 git clone https://git.eff.org/public/observatory.git
 cd observatory

 # get the server response for twitter.com
 ./scan/FasterCertificateGrabber.py twitter.com

 # split it into component PEM certs
 ./inspect twitter.com.results
 cd certs

 # now try to verify it.  Note that allcerts was a poorly chosen
 directory name.  It should have been allCAs...

 openssl verify -untrusted twitter.com.results_2.pem -CApath ../allcerts/
 twitter.com.results_1.pem

 # with openssl 0.9.8*, the above command will print
 # twitter.com.results_1.pem: OK
 #
 # but with 1.0.1c, it gives:
 # twitter.com.results_1.pem: C = US, O = VeriSign, Inc., OU = VeriSign
 Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)06,
 CN = VeriSign Class 3 Extended Validation SSL CA
 # error 20 at 1 depth lookup:unable to get local issuer certificate

 --
 Peter




-- 
Peter

Re: X.509 certificate subject format

[Peter Sylvester]

On 07/02/2012 10:34 AM, Johannes Bauer wrote:

Hi list,

I have a rather simple question regarding X.509 subjects that is not
entirely clear to me and for which I cannot find the appropriate
reference (pointers greatly appreciated). The trouble starts when trying
to compare two subjects of *different* certificates for equality and
becomes worse when certain fields are appearing more than once. To
clarify, by equal I mean 'should behave in exactly the same way by all
well-behaved implementations.

Let's start easy. Consider the following subjects:

subject1= /C=SE/O=FooBar/OU=BarFoo/CN=moo.koo.com
subject2= /C=SE/OU=BarFoo/CN=moo.koo.com/O=FooBar

Are these to be considered equal or not?

Not equal. beware, you are using a textual representation which is
probably the one of openssl. So C=SE is the first in the DN sequence.
Note that there is also the possibility to put several attribute into 
one RDN.

I.e.: Does the order of
elements matter?

Yes.

  Does the order matter when fields are duplicate, i.e. are:

subject1= /CN=foo/CN=bar
subject2= /CN=bar/CN=foo

equal?

No.


If they are not equal, does the first one have a special meaning?

X.509 and RFC 5280 defines a hierachical order of the relative
disdintiguised names that make up the sequence of the distinguished name.

For
example, assume a webserver with a duplicate common name field. Are both
names valid as the server name then?

No.

  I.e. could I access a webserver
with the certificate subject as stated above by DNS foo *and* bar or
only by one of them?

This depends on the implemention of the client, and also whether
you have a subjectAltName extension. If there is a sibjectAltName
extension, the common name is (not supposed to be) used by a client.


One reason to ask for equality is that there maybe is a certificate X:

issuerX = /O=myCA/OU=greatCA/CN=not
subjectX= /CN=foo/CN=bar

and it has a valid signature by a CA with the following subject:

issuerX = /OU=greatCA/O=myCA/CN=not

Is the certificate signature then valid?

The certificate signature may be cryptographically valid,
but not the name chain in a path validation.

At least it shouldn't, there had been errors in some toolkits
in the past that treated the hierarchy as a heap of attributes.

/P



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

AUTO: Peter Birk pb...@us.ibm.com is out of the office until July 16th, 2012

[Peter Birk]

I am out of the office until 07/16/2012.

I'm out of the office until July 16th, 2012.  I will have limited network
access but will likely be checking for urgent emails daily.   If you have
questions about any of the following projects, please contact those listed
below.   For all other questions, please contact my manager Carlos A Hoyos
caho...@us.ibm.com.   Thanks!

IBM Certificate Authority / Client Certificates:Gabriel Pereira Borges
gpbor...@br.ibm.com
Simplified Web SSO:   Michael K Ackerbauer mac...@us.ibm.com
ISAM ESSO 8.2 Pilot:  Michael K Ackerbauer mac...@us.ibm.com
Two-Factor Authentication:   Michael K Ackerbauer mac...@us.ibm.com
Encryption Recovery Service:  Pedro Irlandini Endres de Oliveira
pedr...@br.ibm.com
Endpoint Registration Service:  Pedro Irlandini Endres de Oliveira
pedr...@br.ibm.com

Regards,
Pete


Note: This is an automated response to your message  RE: Client
certificate verification: performance sent on 07/02/2012 20:53:10.

This is the only notification you will receive while this person is away.

Re: Client certificate verification

[Peter Sylvester]

On 06/29/2012 09:29 PM, Sukalp Bhople wrote:

Hello,

I am trying to measure server performance for client certificate verification.

However, there is no significant difference in the server performance when I send one certificate 
and condition when I send chain of 10 certificates.


I am aware that certificate verification is a public key operation. But shouldn't it make some 
difference? is there any cashing mechanism or something else?



cash or cache.  cache is french.


--
Regards,
*Sukalp Bhople.*

Re: self-generated, self-signed root CA and Client Auth Certs not working

[Peter Sylvester]

On 06/05/2012 07:14 PM, DRings wrote:

I've spent too much time trying to figure out something that is probably well
know here.

I have a restricted community application that seems a perfect fit for using
openssl to self-generate our own CA, and self-sign it, and self-generate our
own web client authentication certificate and self-sign them. All this so
that we can validate the Distinguished Name presented when web browser
connecting to our nginx web server.


I assume you mean 'sign it by your CA'


I have done all this many times but have not been able to get various web
browsers to use the self-generated/self-signed client authentication certs.

I have imported both the CA.crt and the client.crt into the OS certificate
store. But after that the web browser does not seem to use the cert for
authentication.

I've tried to set the properties on the imported certificate to be used for
web client authentication. - it just does not work!

Youalso  need to configure your server to ask for client certificates of your 
CA.



I just cannot keep spending time on this problem. If I cannot find help, I
will urge the the requirement for client certs be dropped from the project.

(personal lore) It seems that the web browsers fail because our
self-generated/self-signed CA is not signed by some higher CA that is
trusted. Is that true or false?

They don't fail, they warn that your ca that has signed
your server certificate is not installed by default as a trusted ca.




If it is false, I need help to overcome the failure of the web browsers to
correctly use our certs.

Thanks
David


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: variable response size of openssl rand on windows

[Peter Sylvester]

some new line - CRLF conversion may have hit.

On 06/04/2012 04:29 PM, Ken Goldman wrote:
A typical openssl user error is treating binary data as text.  Random 
numbers are not text until you convert them with -hex.


My guess is that Windows is treating some binary character specially, 
and this causes your version of wc to fail.  Linux is handling the 
binary correctly.  So I doubt it's an openssl bug - just a strange 
interaction with binary streams, Windows, and wc.


On 6/3/2012 6:34 PM, alexis _ wrote:


I tried to generate 100 bytes using openssl rand 100 But i observed
on my Windows machine (openssl from cygwin) that sometimes the result
is not always 100 bytes long, I experienced 101, 102... However,
while using -hex switch, the variable size issue does not seem to
reproduce. Observation does not reproduce at all on Ubuntu 12.04 btw
(see version info below)

Do you guys reproduce the behavior ? Am i missing something obvious ?
is it related to my environment ? is it an openssl bug (i have not
seen anything like this on http://rt.openssl.org/index.html?q=rand)



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Can not enable via padlock

[Peter Kurrasch]

Are you combining version 1.0.1 and 1.0.0 ?


 From: salatiel.fi...@gmail.com
 Subject: Can not enable via padlock
 Date: Wed, 30 May 2012 20:26:45 -0300
 To: openssl-users@openssl.org

 I am trying to test via padlock using 'openssl speed -engine padlock', but it 
 fails.

 # openssl version
 OpenSSL 1.0.1c 10 May 2012

 # openssl engine padlock
 140291115067048:error:260B606D:engine routines:DYNAMIC_LOAD:init 
 failed:eng_dyn.c:521:
 140291115067048:error:2606A074:engine routines:ENGINE_by_id:no such 
 engine:eng_list.c:417:id=padlock

 # strace openssl engine padlock 21 | grep -i padlock.so
 open(/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libpadlock.so, 
 O_RDONLY) = 3

 # ls -la /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libpadlock.so
 -rw-r--r-- 1 root root 6096 May 11 12:51 
 /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libpadlock.so

 # dmesg | grep -i aes
 [ 284.335338] padlock: Using VIA PadLock ACE for AES algorithm.

 # lsmod | grep -i aes
 padlock_aes 5633 0
 aes_generic 25714 1 padlock_aes



 What am i doing wrong ?


 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing List openssl-users@openssl.org
 Automated List Manager majord...@openssl.org
  
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Cert order in .pem format

[Peter Sylvester]

On 05/18/2012 06:03 AM, kthiru...@inautix.co.in wrote:

Team,

Had a query in the certs that we load,

The CA's provide our certs in .p12 format, which we need to convert to a .pem and load to SSL 
structure during initialization.

On converting to .pem, it is in the following format, Private Key, CA Certs and 
Domain Certificate.

In our code, we use the below snippet to load keys in in SSL structure,

1. err =  SSL_CTX_use_certificate_chain_file(ctx, KeyFile);
2. SSL_CTX_set_default_passwd_cb(ctx, passwd);
3. err = SSL_CTX_use_PrivateKey_file(ctx, KeyFile, SSL_FILETYPE_PEM);
4. SSL_CTX_check_private_key(ctx);

When i use the same order in the key ( Private Key, CA Certs and Domain Certificate ), the above 
fails in step 3.
So we have to rearrange this order to Domain Certificate, Private Key and CA Certs for the above 
snippet to work properly.


We are trying to reduce the effort here, for someone to rearrange this cert 
order.
Can you suggest some other way to convert the certs as expected by the code or change the order of 
our code.

load the P12 file directly in your code

Re: Are those TLS-SRP cipher suites supported?

[Peter Sylvester]

On 05/14/2012 02:59 PM, marek.marc...@malkom.pl wrote:

Hello,

$ openssl version
OpenSSL 1.0.0 29 Mar 2010
$ openssl ciphers -V

For SRP one should use the 1.0.1 version.

openssl version
OpenSSL 1.0.1 14 Mar 2012

openssl ciphers SRP
SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3DES-EDE-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: PHP openssl_x509_parse extensions=subjectAltName

[Peter Sylvester]

Yes, it can probably be parsed by any ASN.1 parser. But the OID is
private - only the organization knows how to interpret it (or what to
do with it).

private/public in this context refers to governance/ownership
not to visibility. if the organisation documents the any interested
party can interpret it.  311 is one of microsoft's OID branches

smart cad login with UPN is documented at least in

http://support.microsoft.com/kb/281245
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to trust a 'root' certificate

[Peter Sylvester]

On 04/26/2012 03:58 PM, Tammany, Curtis wrote:

I don't see this as an Apache issue. The site has required client certs for 
years now and Apache was configured to require client certificates.

I have intermediate DOD certs on the server but OpenSSL sees my DoD Root 
certificate as un-trusted self-signed so the chain is broken. From 
http://www.openssl.org/support/faq.html:




 5. Why doesSSL program  fail with a certificate verify error?
This problem is usually indicated by log messages saying something like unable to get local issuer 
certificate or self signed certificate. When a certificate is verified its root CA must be 
trusted by OpenSSL this typically means that the CA certificate must be placed in a directory or file 
and the relevant program configured to read it. The OpenSSL program 'verify' behaves in a similar way and issues 
similar error messages: check the verify(1) program manual page for more information.

How can I get OpenSSL to trust my DOD root certificate?


In general all certificates that you have in the apache as client CAs 
are trusted but they need

to chain up to some root which must be part of the set.

If the certficates are in a directory, and you have changed the openssl 
version, you

might want to rehash. The hash logic had been changed at some version.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to trust a 'root' certificate

[Peter Sylvester]

On 04/26/2012 05:20 PM, Tammany, Curtis wrote:

In my htaccess file I have the following:
SSLRequireSSL
SSLVerifyClient require
SSLVerifyDepth 5
SSLOptions +ExportCertData

In my httpd.conf file, I have the following:
SSLCACertificatePath conf/certs/
SSLCACertificateFile conf/certs/DOD_EMAILCerts.crt

I am not sure which one takes precedence, but having
both is probaly not ok with apache.  Try :

   cd conf/certs/
   c_rehash

That's for linux. But for windows, the openssl logic is
the same, it open the file. opensll doesn't know whether
it is a link or a file.

So 



DOD_EMAILCerts.crt contains the root cert plus many intermediates.

The site has been working fine for the most part for years. We are tracking 
SSL_CLIENT_VERIFY in our log file and with some Windows 7 clients, they cannot connect 
and we are seeing  FAILED:unable to get local issuer certificate in the log.

As I said in an earlier email, used the openssl version -d command and it responded: 
OPENSSLDIR: c:/openssl-1.0.1/ssl That folder does not exist.
Running openssl verify DOD_EMAILCerts.crt (with the cert file in the bin 
folder) returns:
DOD_EMAILCerts.crt: C = US, O = U.S. Government, OU = DoD, OU = PKI, CN = DoD 
Root CA 2
error 18 at 0 depth lookup:self signed certificate
OK
with that command you are verifying the first cert in that file, and 
since it

it is probably self signed, you cannot do that.

If, on the other hand you happen to have an intermediate as the
beginning you get the other cannot find issuer message.




 From http://www.madboa.com/geek/openssl/ I read:
 error 18 at 0 depth lookup:self signed certificate. Unless you make an exception, 
OpenSSL won’t verify a self-signed certificate.

They also go on to say:
 How do I get OpenSSL to recognize/verify a certificate?
Put the file that contains the certificate you’d like to trust into the certs 
directory discussed above. Then create the hash-based symlink. Here’s a little 
script that’ll do just that.

#!/bin/sh
#
# usage: certlink.sh filename [filename ...]

for CERTFILE in $*; do
   # make sure file exists and is a valid cert
   test -f $CERTFILE || continue
   HASH=$(openssl x509 -noout -hash -in $CERTFILE)
   test -n $HASH || continue

   # use lowest available iterator for symlink
   for ITER in 0 1 2 3 4 5 6 7 8 9; do
 test -f ${HASH}.${ITER}  continue
 ln -s $CERTFILE ${HASH}.${ITER}
 test -L ${HASH}.${ITER}  break
   done
done

That is for Linux.
How do I get OpenSSL to recognize/verify a certificate on Windows XP/2003? 
(like step-by-step instructions).

... instead of ln -s you can create a copy ...
for more detailed instruction, I'll can charge you 100EUR per line. :-)
...


... Just put all the CA certificates into one file and remove the

SSLCACertificatePath

and just keep the

SSLCACertificateFile



Thanks.

Curtis


-Original Message-
From: Peter Sylvester [mailto:peter.sylves...@edelweb.fr]
Sent: Thursday, April 26, 2012 10:40
To: openssl-users@openssl.org
Cc: Tammany, Curtis; Bernhard Fröhlich
Subject: Re: How to trust a 'root' certificate

On 04/26/2012 03:58 PM, Tammany, Curtis wrote:

I don't see this as an Apache issue. The site has required client certs for 
years now and Apache was configured to require client certificates.

I have intermediate DOD certs on the server but OpenSSL sees my DoD Root 
certificate as un-trusted self-signed so the chain is broken. From 
http://www.openssl.org/support/faq.html:
 5. Why doesSSL program   fail with a certificate verify error?
This problem is usually indicated by log messages saying something like unable to get local issuer 
certificate or self signed certificate. When a certificate is verified its root CA must be 
trusted by OpenSSL this typically means that the CA certificate must be placed in a directory or file 
and the relevant program configured to read it. The OpenSSL program 'verify' behaves in a similar way and issues 
similar error messages: check the verify(1) program manual page for more information.

How can I get OpenSSL to trust my DOD root certificate?



In general all certificates that you have in the apache as client CAs
are trusted but they need
to chain up to some root which must be part of the set.

If the certficates are in a directory, and you have changed the openssl
version, you
might want to rehash. The hash logic had been changed at some version.





__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: RE: OpenSSL 1.0.1a

[Peter Heimann]

On 01/-10/-28163 08:59 PM, Spence, Thomas CIV USAF AFDW 844 CS/SCOX wrote:
 I am using AIX 5.3 with gcc 4.3.5.

 ld: 0711-317 ERROR: Undefined symbol: OPENSSL_ia32cap_P

I had the same problem with the file crypto/evp/e_rc4_hmac_md5.c.
Linking on non-x86 hardware failed.
Try to replace this file with a newer version from
openssl-1.0.1-stable-SNAP-20120420.tar.gz (or a later snapshot).

-- 
Peter Heimann
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: SRP in OpenSSL 1.0.1

[Peter Sylvester]

On 04/04/2012 11:01 AM, Christian Weber wrote:

Dear users and developers,

we just read through some of the code examples for SRP usage.

Concerning the necessary callbacks we wonder why in
s_server.c the verifier parametrization is being delayed.

Within apps/s_server.c we can find the comment:

 When the callback is called for a new connection we return
  with a negative value. This will provoke the accept etc to return with
  an LOOKUP_X509. The main logic of the reinvokes the suspended call
  (which would normally occur after a worker has finished) and we
  set the user parameters.

There seems to be something missing between 'the' and 'reinvokes',
so we cannot understand what's being meant.


application:

Imagine a server that has a large base of users. When the callback is
invoked, it would start with some asynch ldap call or whaever else
to read a verifier. The callback would return -1, and the SSL_accept
fails with the return code ERROR_LOOKUP_X509 (well, I know, by this
name was the only one available, borrowed by a reciprooque feature
in the client. The application would do some select call on whatever
filedescriptors. As soon as the verifier is available, the application
stores this somewhere, and calls SSL_accept again, which in this
case will cause the callback to return the verifier.

Nothing about srp is documented so far.

The code in apps/server.c is not doing any select loop, it just
calls the SSL_accept twice. This is done to illustrate the
possibilities of the callback. The callback 'pretends' that
the data are not there.

I do not really like to use the verifier file as it is done in the example,
since one needs to restart a server after modifying a user.



May it be a security impact to implement the lookup within the
callback itself (as done in ssl/ssltest.c, based on user's password)
or may there be other error conditions which are covered by
relocating the lookup to init_ssl_connection in apps/s_cerver.c?

As I wrote abone, the while loop to do SSL_accept is not exactly
what you would want to do in a real application.

The simulated logic flow  is:

i=SSL_accept(con);

  if (  i = 0   SSL_get_error(con,i) == SSL_ERROR_WANT_X509_LOOKUP )

do whatever is necessary to get the verifier, in this case simulated by

   srp_callback_parm.user = SRP_VBASE_get_by_user(srp_callback_parm.vb, 
srp_callback_parm.login);

   since there is nothing async to do in the example.

  and then do another

   i=SSL_accept(con);

I could have folded out the loop to get out the init_ssl_connection etc.




Any opinions about possible security weakening against implementing
the lookup within the callback?


There may be many ways to store and create a verifier.
One could for example on the fly generate a one time password,
send it as an SMS, store the verifiers in an LDAP.

Therefore the callback allows an application to choose whatever means
it wants to implement, openssl is not charged to read files, make network
requests or whatever.


Peter


TIA
-- Christian Weber
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to get the Certificate Keyusage retire error ? (lCert-ex_kusage =0)

[Peter Sylvester]

On 04/04/2012 02:51 PM, brajan wrote:

I am using openssl 0.9.8g version .

i convert the PEM certificate file to X509 format and try to read the key
usage value .
Keyuage =lCertificate-ex_kusage ;

Some time the keyusage = 128
Some time Keyusage is 0 for the same certificate . why this problem occurs
...

the flags are set by one of functions in crypo/v3_purp.c


try callX509_check_ca(lCertificate)   before accessing


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: 1.0.1beta1, incompatibility with gnutls?

[Peter Sylvester]

On 03/08/2012 11:05 PM, David Holmes wrote:

I'm trying to use openssl 1.0.1beta1 s_server with gnutls 2.4.1 (gnutls-cli).

s_server is complaining of an unknown extension (see debug output below).

Isn't it the client after the serverhello response?

you might want to add  -debug and -msg to see the s_server response
to what s_server responds and why the client aborts.


regarding my earlier hasty message today:
the illegal hostname 17.0.0.1 is not a problem in s_server.
(I still haven't passed all ent certification) :-)



Openssl 0.9.8h works just fine though.

Is this a known issue?


./openssl s_server -key src/data/server.key -cert src/data/server.crt 
-tlsextdebug
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
TLS client extension unknown (id=9), len=3
 - 02 00 01  ...
TLS client extension server name (id=0), len=14
 - 00 0c 00 00 09 31 32 37-2e 30 2e 30 2e 31 .127.0.0.1
ERROR
4150167176:error:14094456:SSL routines:SSL3_READ_BYTES:tlsv1 unsupported 
extension:s3_pkt.c:1240:SSL alert number 110
shutting down SSL
CONNECTION CLOSED
ACCEPT

David Holmes  |  Technical Marketing Manager - Security
F5 Networks 
   P 206.272. 
F 206.272.5556
www.f5.com 
   D 206.272.6740 
Follow @dholmesf5 
  



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: 1.0.1beta1, incompatibility with gnutls?

[Peter Sylvester]

On 03/08/2012 11:05 PM, David Holmes wrote:

I'm trying to use openssl 1.0.1beta1 s_server with gnutls 2.4.1 (gnutls-cli).

s_server is complaining of an unknown extension (see debug output below).

Openssl 0.9.8h works just fine though.

Is this a known issue?

try beta3, should work better.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: 1.0.1beta1, incompatibility with gnutls?

[Peter Sylvester]

On 03/08/2012 11:05 PM, David Holmes wrote:

I'm trying to use openssl 1.0.1beta1 s_server with gnutls 2.4.1 (gnutls-cli).

s_server is complaining of an unknown extension (see debug output below).

Openssl 0.9.8h works just fine though.

Is this a known issue?


127.0.0.1  is not a valid servername.

I don't remember but you might want to play
with the servername parameter of s_server.





./openssl s_server -key src/data/server.key -cert src/data/server.crt 
-tlsextdebug
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
TLS client extension unknown (id=9), len=3
 - 02 00 01  ...
TLS client extension server name (id=0), len=14
 - 00 0c 00 00 09 31 32 37-2e 30 2e 30 2e 31 .127.0.0.1
ERROR
4150167176:error:14094456:SSL routines:SSL3_READ_BYTES:tlsv1 unsupported 
extension:s3_pkt.c:1240:SSL alert number 110
shutting down SSL
CONNECTION CLOSED
ACCEPT

David Holmes  |  Technical Marketing Manager - Security
F5 Networks 
   P 206.272. 
F 206.272.5556
www.f5.com 
   D 206.272.6740 
Follow @dholmesf5 
  



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Distinguishing a CA certificate from an end entity certificate Reg.

[Peter Sylvester]

On 02/23/2012 10:49 AM, Ashok C wrote:

Hi,

What would be the most efficient and easiest way to distinguish a CA certificate from an actual 
server/client(end entity) certificate?
We were thinking of identifying the CA with the CA:TRUE constraint from the text display, but 
again this check does not cover x509 v1 certificates where this extension is not present.

Is there any command/openSSL API available which would serve this purpose?


a v1 certificate (if you want)
or v3 cert with both CA:true*and keyusage has certsign bit.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Customer Enterprise X.509 Extension OID Assignment

[Peter Sylvester]

On 02/06/2012 09:41 AM, Curt Sampson wrote:


If I were to create a custom X.509 certificate extension for use within
my enterprise and with others outside who wanted to write or modify
their own software to interoperate with it, I'd need to assign an OID
for this extension, right? And for that, would the standard way to do
this be to assign an OID underneath the one assigned to us by the IANA
in their Private Enterprise Number list[1], right?

It is one possible way, you need to find someone that
owns an OID (forever) and dedicates you a number.

in france, every enterprise has an oid 1.3.2.officialenterprisenumber

some institution sell such numbers.



(I note that [1] claims to be the SMI Network Management Private
Enterprise Codes, but I gather that others use this for pretty much
anything where they need a unique OID.)

I'd prefer to say non-ambiguous.

besides that, I would also investigate your need for a custom extension,
if you use it for 'identity', then use a subjectAltname for example
if you use it for some kind  of attribute based authorisation, well,
you are maybe overloading the certificate.

Peter

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

reference docs at old sial.org

[Peter N. Steinmetz]

Hi,

Just wanted to let the users of openssh know that the old reference documents 
from sial.org, which provided a handy discussion of maintaining a certificate 
authority and other aspects of use of openssh, are now back online at 
http://novosial.org. 

The sial.org domain was sold several years ago and the contents replaced by the 
domain name reseller. Since the original author, Jeremy Mates, placed the 
documents in the public domain, they are available online again in one 
collection at this new site.

cheers,
Peter N. Steinmetz


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Separating the digest and signature steps of RSA signing

[Peter Eckersley]

Hi all,

I have an offline system that needs to compute RSA signatures over
large blobs of data, given only hashes of the data as input and not
the entire blobs (something like the NONEwithRSA algorithm in Java's
RSA implementation
http://www.docjar.com/docs/api/sun/security/mscapi/RSASignature.html)

Is there any way to do that with openssl?

-- 
Peter
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: SRP problem in OpenSSL 1.0.1 beta

[Peter Sylvester]

On 01/10/2012 04:52 AM, Norm Green wrote:

Hi,

I am testing my application with the 1.0.1 beta and noticed the errors generated are not 
very friendly when SRP credentials are incorrect.  The problem is that the error codes 
returned in no way indicate that the problem is incorrect credentials.  Instead I see 
errors about bad record mac (see below).

two things:

- your server code may choose to react with a

  o  unknown_psk_identity (115) - this alert MAY be sent by a server
  that receives an unknown user name.  This alert is always fatal.
  SeeSection 2.5.1.3  http://tools.ietf.org/html/rfc5054#section-2.5.1.3  
for details.

  this can be done in the callback if one chooses so.

- when a user provides a bad password, there is no common secret,
  there is only one possible error:
something was wrong during the handshake



Everything works just fine when the correct credentials are used.  What I need 
a way to discern if incorrect credentials were supplied, or there is some other 
error.  As it stands now, I would have to assume that the credentials are wrong 
whenever SSL_connect() or SSL_accept() fail, which seems like a poor assumption.

You can only assume that either a wrong password is given or
some network problem has occured.

You cannot determine whether you are talking to the right partner
without a successful handshake.




I'm still fairly new to SSL and SRP and am grateful for any and all help.

does that help?

btw: if your server needs non blocking behaviour (even if no),
and you need time to lookup a credential (a verifier) in a database,
you can indicate in your callback to interrupt the accept call
(in blocking and non blocking mode) and repeat the accept as
soon as the data are there.



Norm Green
VMware, Inc.




Peter Sylvester

Re: SRP problem in OpenSSL 1.0.1 beta

[Peter Sylvester]

an excerpt from rfc 5054 paragraph 3.3


   If an attacker learns a user's SRP verifier (e.g., by gaining access
   to a server's password file), the attacker can masquerade as the real
   server to that user, and can also attempt a dictionary attack to
   recover that user's password.

   An attacker could repeatedly contact an SRP server and try to guess a
   legitimate user's password.  Servers SHOULD take steps to prevent
   this, such as limiting the rate of authentication attempts from a
   particular IP address or against a particular user name.

...

   If the client receives an unknown_psk_identity alert in response to
   a client hello, this alert may have been inserted by an attacker.
   The client should be careful about making any decisions, or forming
   any conclusions, based on receiving this alert

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Displaying Serial Number of Cert via s_client ?

[Peter Sylvester]

On 01/07/2012 02:01 AM, Ken Adler wrote:

I use  echo GET | openssl s_client -connect www.google.com:443 -state to 
troubleshoot https handshakes.

Is there a way to get it to return the Serial number (or thumbprint) of the 
server certificate?



openssl s_client -connect www.google.com:443 21|openssl x509 -noout -serial

serial=4F9D96D966B0992B54C2957CB4157D4D

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL and apache2 wildcard self-signed certificate for nested subdomain

[Peter Sylvester]

On 12/14/2011 01:33 PM, rey sebastien wrote:


Hello users :)

I have some problem with nested subdomain and wildcard openssl certificate.. perhaps this is 
because the subdomain type is : site1.parisgeo.cnrs.fr, or site2.parisgeo.cnrs.fr, or other 
subdomain like .parisgeo.cnrs.fr


When i create the self signed certificate, i enter CN = *.parisgeo.cnrs.fr, but it's seems it's 
impossible to connect on this site for example partage.parisgeo.cnrs.fr with this configuration ! Arg.



your connexion works fine up to the point of certificate verification.

openssl s_client does not like self signed certs
any browser needs user action to disable warnings.

example  curl -k https://www.parisgeo.cnrs.fr  works because of -k

Re: revoking a certificate without having to provide pass phrase as next step

[Peter]

I know. that's why i'm looking for a way, where I can provide it in some
way other than needing to interact with system.

2011/11/29 Curt Sampson c...@cynic.net

 On 2011-11-29 04:15 +0100 (Tue), Peter wrote:

  It generally works, but after the command above is sent, i have to type
 in
  pass phrase manually. I need it to be done automatically.

 I believe you can just remove the passphrase from the key file. This of
 course has the obvious security implications.

 cjs
 --
 Curt Sampson c...@cynic.net +81 90 7737 2974
 http://www.starling-software.com/
 I have always wished for my computer to be as easy to use as my telephone;
 my wish has come true because I can no longer figure out how to use my
 telephone.  --Bjarne Stroustrup
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

revoking a certificate without having to provide pass phrase as next step

[Peter]

Hi,

I'm trying to find a way to make my PHP scipt capable of automatic
certificate revocation.

The script is run from console and the line looks like this:
exec(openssl ca -keyfile ca.key -cert ca.pem -revoke .$userId..pem);

which works like this:
openssl ca -keyfile ca.key -cert ca.pem -revoke 04.pem

It generally works, but after the command above is sent, i have to type in
pass phrase manually. I need it to be done automatically. Is there any way
to achieve this? I looked through manual but didn't find any information on
how and if this could be done.

Regards,
Peter

Re: How to create certificate store using DER and PKCS12 certificates

[Peter Sylvester]

On 11/10/2011 12:47 PM, Rajib Karmakar wrote:


Hi,

I am using OpenSSL version 1.0.0e and want to create a certificate 
store using DER and PKCS12 formatted certificates.



I have to read and convert DER and PKCS12 certificates into X509 
object and add them into X509_STORE.
But if PEM, DER and PKCS12 certificates are stored in same path I have 
to identify each certificate format.


Is there any OpenSSL API that tells the certificate format?


You try to decode them in all formats, only one of them will succeed.

Re: OpenSSL 1.0.1 example with SRP

[Peter Sylvester]

On 10/25/2011 05:15 AM, Norm Green wrote:

Hello Experts,

I'm new to OpenSSL so please bear with me.

I'm trying to construct a simple example that uses a recent OpenSSL 1.0.1 
snapshot to create secure connection using SRP without using any certificates.  
I am aware 1.0.1 is not yet released, but I've been told this should be 
possible.

try this first with s_client and s_server   you need cipher SRP fo them

what happens when you connect to your server with

  openssl s_client -srpuser USER -cipher SRP -connect server:port



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Unable to enable GOST ciphers support

[Peter Volkov]

Hi! I'm trying to enable GOST ciphers in openssl-1.0.0e and so far I
failed. What I've done so far:

1. built openssl with ./config shared zlib enable-rfc3779
--prefix=/tmp/gost-ssl-new
2. updated config file as described in README.gost. 

I've straced openssl run and I'm sure it reads my configuration file
(attached to this mail) and I'm sure there
is /tmp/gost-ssl-new/lib/engines/libgost.so. But nevertheless openssl
does not open this binary (conclusions from strace) and no GOST ciphers
available. I've tried to do exactly same steps installing openssl system
wide (prefix=/usr) but still no luck. Could you help me to understand
what am I doing wrong? Is there any way to debug what openssl loads from
configuration file and how it parses that?

Thank you in advance for any pointers,
--
Peter.


HOME= .
RANDFILE= $ENV::HOME/.rnd

engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
dynamic_path = /tmp/gost-ssl-new/lib/engines/libgost.so
default_algorithms = ALL
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet


tablet gost-ssl-new # strace -e open ./bin/openssl ciphers 
open(/tmp/gost-ssl-new/lib/tls/x86_64/libssl.so.1.0.0, O_RDONLY) = -1 ENOENT 
(No such file or directory)
open(/tmp/gost-ssl-new/lib/tls/libssl.so.1.0.0, O_RDONLY) = -1 ENOENT (No 
such file or directory)
open(/tmp/gost-ssl-new/lib/x86_64/libssl.so.1.0.0, O_RDONLY) = -1 ENOENT (No 
such file or directory)
open(/tmp/gost-ssl-new/lib/libssl.so.1.0.0, O_RDONLY) = 3
open(/tmp/gost-ssl-new/lib/libcrypto.so.1.0.0, O_RDONLY) = 3
open(/tmp/gost-ssl-new/lib/libdl.so.2, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/etc/ld.so.cache, O_RDONLY)  = 3
open(/lib64/libdl.so.2, O_RDONLY) = 3
open(/tmp/gost-ssl-new/lib/libz.so.1, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/lib64/libz.so.1, O_RDONLY)  = 3
open(/tmp/gost-ssl-new/lib/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/lib64/libc.so.6, O_RDONLY)  = 3
open(/tmp/gost-ssl-new/ssl/openssl.cnf, O_RDONLY) = 3
open(/proc/meminfo, O_RDONLY) = 3
open(/dev/urandom, O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:IDEA-CBC-SHA:PSK-AES128-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5

Re: Error converting from .cer to .pem

[Peter Sylvester]

On 09/19/2011 04:29 PM, ubuntuv wrote:

Thanks Jacob.

Output of
#less evalRootCertificate.cer

-BEGIN CERTIFICATE-
MIICBDCC.MVWn1dH/IzvUWbQ==
-END CERTIFICATE-

I even tried removing the following file lines

-BEGIN CERTIFICATE-
-END CERTIFICATE-

# openssl x509 -inform der -in evalRootCertificate.cer -out steel.pem
unable to load certificate

your file is already in pem form.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to deal with new OIDs

[Peter Sylvester]

On 09/07/2011 08:28 PM, Dr. Stephen Henson wrote:

On Wed, Sep 07, 2011, Dominik Oepen wrote:



Are these OIDs are by chance the ones described in ticket 1794?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to deal with new OIDs

[Peter Sylvester]

On 09/08/2011 04:31 PM, Dominik Oepen wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 08.09.2011 11:49, schrieb Peter Sylvester:

On 09/07/2011 08:28 PM, Dr. Stephen Henson wrote:

On Wed, Sep 07, 2011, Dominik Oepen wrote:


Are these OIDs are by chance the ones described in ticket 1794?


Actually I meant 2239.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Becoming a CA for group of internal servers?

[Peter Sylvester]

you might want to read the description of the -extfile parameter of the x509 
command

an excerpt from   curl-7.21.6/tests/certs/scripts/genserv.sh  available at  
curl.haxx.se

$OPENSSL req -config $PREFIX-sv.prm -newkey rsa:$KEYSIZE -keyout $PREFIX-sv.key 
-out $PREFIX-sv.csr
$OPENSSL rsa -in $PREFIX-sv.key -out $PREFIX-sv.key
$OPENSSL x509 -set_serial $SERIAL -extfile $PREFIX-sv.prm -days $DURATION  -CA $CAPREFIX-ca.cacert 
-CAkey $CAPREFIX-ca.key -in $PREFIX-sv.csr -req -out $PREFIX-sv.crt -text -nameopt multiline -sha1


with a $PREFIX-sv.prm like the following

extensions = x509v3
[ x509v3 ]
subjectAltName = DNS:localhost
keyUsage= keyEncipherment
extendedKeyUsage = serverAuth
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid
basicConstraints = critical,CA:false
[ req ]
default_bits= 1024
distinguished_name  = req_DN
default_md= sha256
string_mask= utf8only
[ req_DN ]
countryName = Country Name is Northern Nowhere
countryName_value= NN
organizationName  = Organization Name
organizationName_value = Edel Curl Arctic Illudium Research Cloud
commonName  = Common Name
commonName_value  = localhost

[something]
# The key
# the certficate
# some dhparam

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org