Re: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates

[Matt Caswell]

On 16/11/15 06:52, Jayalakshmi bhat wrote:
> Hi Victor,  
> 
> Thanks a lot for details explanation.
> 
> Our device acts as TLS/SSL client.  The device receives chain of
> certificates as part of SSL handshake, when it is trying to get
> connected to TLS/SSL server like sharepoint 365.
> 
> While validating the certificate chain from server, "*check_trust"
> *fails with X509_V_ERR_CERT_UNTRUSTED. 
> 
> This had been working fine with OpenSSL 1.0.1c. 
> 
> When I checked the code execution, check_trust was not being called  in
> OpenSSL 1.0.1c as "if (param->trust > 0)" was not satisfied.
> 
> That is why I wanted to know is it mandatory for the applications to
> set X509_VERIFY_PARAM in X509_STORE_CTX


Are you able to share the certificates that the server provides you
with? Also the root certificate you are using.

It is not mandatory to set X509_VERIFY_PARAMs (but typically you at
least want to verify the hostname through a call to
"X509_VERIFY_PARAM_set1_host"). Are you currently do anything like this?

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

Re: [openssl-users] Available ciphers

[Dirk Menstermann]

Anybody able to help?

Thanks
Dirk

On 10.11.2015 17:09, Dirk Menstermann wrote:
> Hi,
> 
> I'm using openssl 1.0.2 (as web server application) and utilize the APLN
> callback to react on protocols offered by the client. In this callback I need 
> a
> way to get the list of ciphers that the client sends within the client_hello.
> 
> Background is that http2 should only be negotiated if client supports
> "ECDHE-RSA-AES128-GCM-SHA256" (like Firefox). Any idea how I can get this
> information?
> 
> Thanks a lot
> Dirk
> ___
> 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] Incompatibility between OpenSSL 1.0.2 and FIPS 2.0.10

[Sebastian Stolzenberg]

Hi,

I am seeing crashes in OpenSSL 1.0.2d when using it with the FIPS 2.0.10
object module.

Apparently the size of
  struct ec_group_st
(in crypto/ec/ec_lcl.h) differs between 1.0.1 and 1.0.2, since 
  BN_MONT_CTX *mont_data; /* data for ECDSA inverse */
has been added to it.

The FIPS module still uses the 1.0.1 version of struct ec_group. That leads
to crashes when ownership is transferred between the FIPS module and
OpenSSL. I.e. when an ec_group object is allocated by the FIPS version of
EC_GROUP_new and then destroyed by the OpenSSL variant of OPENSSL_free.

Am I using the FIPS object module wrongly or is not compatible to OpenSSL
1.0.2 when it comes to EC crytpography?

If 1.0.2 is not supported by FIPS 2.0.10, are there any plans to get
another, compatible version of the FIPS object module validated?

Thanks!
Sebastian

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

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Emilia Käsper]

Thanks all for your feedback!

I asked for mainstream use-cases for algorithms whose removal could cause
widespread pain. Some individual users, undoubtedly, will be hit by this,
and I acknowledge that they may not be reading this list. But I wanted to
know if I'd missed something endemic. I also asked elsewhere: Adam Langley
pointed me to the MD4 use-case and Steve confirmed that RC2 must stay.

There is a tradeoff: by attempting to accommodate every single use-case, we
will weaken the library for a substantial amount of our user base, by
offering them bad defaults, or simply by virtue of the fact that our
developer resources are not infinite. (Near)-dead code is a liability.

So far, excluding suspicions that something may be used somewhere, I've
received one clear argument, for RC5. And, while I'm sympathetic to the
cause, I believe this is the case where we have to balance one user's needs
against everyone else's.

As for specific deprecation strategies:
- Don't forget that all applications will have to recompile against 1.1.

- Disabling algorithms doesn't work well for us as it's just pushing the
decision on the distros. It also wouldn't win us any resources as we'd
still be responsible for keeping the code bug-free. The only win would be
in default compiled code size.

- We can leave OPENSSL_NO_XXX defines around so wrapper libraries (Python,
PHP etc) who correctly account for the fact that an implementation may be
missing (which they have to, anyway) will continue to work.

- Removing assembly support is a GREAT suggestion to simplify the
complexity, and I think we should do this for anything we end up leaving
in, and perhaps even for some things not yet on the hit list (RC4?).

- I appreciate OpenSSL's role as a "Swiss army knife" research tool but
research needs shouldn't prevail over those of real applications. We are
generally not on the frontline of deprecating things - RC4 isn't yet on the
list. SSLv3 isn't yet on the list, etc. But we can't become the Internet
Archive of All Old Crypto either, and there's some cleanup to do that's
long overdue.

- I believe that the OpenSSL community generally tends to overlook the
positive impact of change when trying to round up the negative impact of
breakage. Applications are generally able to move along and fix things when
presented with the right incentives. Applications that aren't generally
able to move along are rather unlikely to jump onto OpenSSL 1.1, and all
these algorithms will be supported as part of OpenSSL 1.0.2 until 2020 for
them. Finally, removing support for these algorithms from OpenSSL doesn't
render your encrypted storage inaccessible. You can always use another
implementation to decrypt/re-encrypt your data, and I fully believe in the
power of the community in providing such tools where necessary.

- Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty
widespread MySQL breakage. That made MySQL backport a change increasing the
DH key length from 512 to 2048 bits. For end user security, it's a win. I
would prefer that we start cashing in these improvements before the next
Logjam happens. (This is my view; as you can see views differ even within
the team.)

- On binary elliptic curves: with recent cryptographic advances, I believe
these are now firmly planted in the "internet archive" category, even if
not practically broken yet. The other reason for removing these is that our
implementations are crappy. They're not constant-time, and they've been
shown to contain bugs. Improving upon these implementations is not a good
use of dev time imo, given their decreasing credibility.

Here's the list of algorithms gone from BoringSSL:

IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves

This isn't of course entirely representative of widespread usage. However
Google's multi-billion line codebase now builds against BoringSSL and
therefore largely does not depend on these algorithms. Those billions of
lines aren't all new and shiny code written in 2015, and some of it does
have to interoperate with the outside world.

And here's the list gone from LibreSSL, from what I can tell:

MD2, MDC2, RC5, SEED

Neither have removed CAST, and there is presumably a good reason for that.
(PGP?)

It seems to me that these can pretty safely go:

MD2 - (The argument that someone somewhere may want to keep verifying old
MD2 signatures on self-signed certs doesn't seem like a compelling enough
reason to me. It's been disabled by default since OpenSSL 1.0.0.)
MDC2
SEED
RC5

These could probably stay (C only):

CAST
IDEA
RIPEMD (used in Bitcoin?)
WHIRLPOOL

as well as

BLOWFISH
MD4
RC2

I am on the fence about the binary curves: I am not aware of any usage,
really, and it's not about to pick up now.

Cheers,
Emilia

On Mon, Nov 16, 2015 at 2:21 PM, Hubert Kario  wrote:

> On Friday 13 November 2015 14:40:33 Emilia Käsper wrote:
> > Hi all,
> >
> > We are considering removing from OpenSSL 1.1 known broken or outdated
> > cryptographic primi

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Viktor Dukhovni]

On Mon, Nov 16, 2015 at 04:51:10PM +0100, Emilia Käsper wrote:

> As for specific deprecation strategies:
> - Don't forget that all applications will have to recompile against 1.1.

The EVP_get_cipherbyname() and EVP_get_digestbyname() interfaces
remain, so nothing changes at compile-time.  Most code does not
use EVP_() directly.  This means that:

* Most errors are not caught at compile time.

* Porting is not the difficult part, the much more difficult
  problem is dealing with runtime access to any algorithms needed
  to handle data at rest.

> - Disabling algorithms doesn't work well for us as it's just pushing the
> decision on the distros. It also wouldn't win us any resources as we'd
> still be responsible for keeping the code bug-free. The only win would be
> in default compiled code size.

Removing assembly support would substantially lower support cost.
For many of the algorithms we can likely find a reference implementation
in an RFC or similar standards document, if our own code is
substantially more refined (and requires greater support effort).

> - We can leave OPENSSL_NO_XXX defines around so wrapper libraries (Python,
> PHP etc) who correctly account for the fact that an implementation may be
> missing (which they have to, anyway) will continue to work.

These don't help with EVP "by name" indirection.

> - Removing assembly support is a GREAT suggestion to simplify the
> complexity, and I think we should do this for anything we end up leaving
> in, and perhaps even for some things not yet on the hit list (RC4?).

Yes, and probably.

> - I appreciate OpenSSL's role as a "Swiss army knife" research tool but
> research needs shouldn't prevail over those of real applications. We are
> generally not on the frontline of deprecating things - RC4 isn't yet on the
> list. SSLv3 isn't yet on the list, etc. But we can't become the Internet
> Archive of All Old Crypto either, and there's some cleanup to do that's
> long overdue.

Researchers can indeed use older toolkits, my concern is real users,
with non-SSL applications (data at rest).

> - Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty
> widespread MySQL breakage. That made MySQL backport a change increasing the
> DH key length from 512 to 2048 bits. For end user security, it's a win. I
> would prefer that we start cashing in these improvements before the next
> Logjam happens. (This is my view; as you can see views differ even within
> the team.)

This is SSL/TLS where we have algorithm agility.  I support the
Logjam changes.  It is likely time for us to take the next (not
final) step from 768 to 1024 as the min prime size.

> - On binary elliptic curves: with recent cryptographic advances, I believe
> these are now firmly planted in the "internet archive" category, even if
> not practically broken yet. The other reason for removing these is that our
> implementations are crappy. They're not constant-time, and they've been
> shown to contain bugs. Improving upon these implementations is not a good
> use of dev time imo, given their decreasing credibility.

I agree they need to go from SSL/TLS.  What about S/MIME and CMS?

> Here's the list of algorithms gone from BoringSSL:
> 
> IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves

Boring SSL has a very narrow user base.  By all means drop
as much as you can get away with.

> And here's the list gone from LibreSSL, from what I can tell:
> 
> MD2, MDC2, RC5, SEED

Likewise, not a wide user base.  We can make incremental steps,
drop assembly support and SSL/TLS codepoints in this release, and
assess things from there.  My hope is that the support cost of a
stable reference implementation in C (yes, likely not constant
time) is not that onerous.

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

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Jakob Bohm]

On 16/11/2015 16:51, Emilia Käsper wrote:

Thanks all for your feedback!

I asked for mainstream use-cases for algorithms whose removal could 
cause widespread pain. Some individual users, undoubtedly, will be hit 
by this, and I acknowledge that they may not be reading this list. But 
I wanted to know if I'd missed something endemic. I also asked 
elsewhere: Adam Langley pointed me to the MD4 use-case and Steve 
confirmed that RC2 must stay.


There is a tradeoff: by attempting to accommodate every single 
use-case, we will weaken the library for a substantial amount of our 
user base, by offering them bad defaults, or simply by virtue of the 
fact that our developer resources are not infinite. (Near)-dead code 
is a liability.


So far, excluding suspicions that something may be used somewhere, 
I've received one clear argument, for RC5. And, while I'm sympathetic 
to the cause, I believe this is the case where we have to balance one 
user's needs against everyone else's.


As for specific deprecation strategies:
- Don't forget that all applications will have to recompile against 1.1.

- Disabling algorithms doesn't work well for us as it's just pushing 
the decision on the distros. It also wouldn't win us any resources as 
we'd still be responsible for keeping the code bug-free. The only win 
would be in default compiled code size.


- We can leave OPENSSL_NO_XXX defines around so wrapper libraries 
(Python, PHP etc) who correctly account for the fact that an 
implementation may be missing (which they have to, anyway) will 
continue to work.


- Removing assembly support is a GREAT suggestion to simplify the 
complexity, and I think we should do this for anything we end up 
leaving in, and perhaps even for some things not yet on the hit list 
(RC4?).


- I appreciate OpenSSL's role as a "Swiss army knife" research tool 
but research needs shouldn't prevail over those of real applications. 
We are generally not on the frontline of deprecating things - RC4 
isn't yet on the list. SSLv3 isn't yet on the list, etc. But we can't 
become the Internet Archive of All Old Crypto either, and there's some 
cleanup to do that's long overdue.
There is also the point that OpenSSL is the worlds most well known 
"Swiss army knife" crypto package for non-research uses.  The more you 
overfocus on the single SSL/TLS use case, the less attractive OpenSSL 
becomes to all other uses.  If OpenSSL makes itself useless, others will 
have to reinvent it.


- I believe that the OpenSSL community generally tends to overlook the 
positive impact of change when trying to round up the negative impact 
of breakage. Applications are generally able to move along and fix 
things when presented with the right incentives. Applications that 
aren't generally able to move along are rather unlikely to jump onto 
OpenSSL 1.1, and all these algorithms will be supported as part of 
OpenSSL 1.0.2 until 2020 for them. Finally, removing support for these 
algorithms from OpenSSL doesn't render your encrypted storage 
inaccessible. You can always use another implementation to 
decrypt/re-encrypt your data, and I fully believe in the power of the 
community in providing such tools where necessary.


- Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty 
widespread MySQL breakage. That made MySQL backport a change 
increasing the DH key length from 512 to 2048 bits. For end user 
security, it's a win. I would prefer that we start cashing in these 
improvements before the next Logjam happens. (This is my view; as you 
can see views differ even within the team.)
The Logjam protection was an SSL-only change.  It has NO relevance to 
the deleterious effects of crippling the non-SSL functionality in the 
OpenSSL libraries.


- On binary elliptic curves: with recent cryptographic advances, I 
believe these are now firmly planted in the "internet archive" 
category, even if not practically broken yet. The other reason for 
removing these is that our implementations are crappy. They're not 
constant-time, and they've been shown to contain bugs. Improving upon 
these implementations is not a good use of dev time imo, given their 
decreasing credibility.


Here's the list of algorithms gone from BoringSSL:

IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves

This isn't of course entirely representative of widespread usage. 
However Google's multi-billion line codebase now builds against 
BoringSSL and therefore largely does not depend on these algorithms. 
Those billions of lines aren't all new and shiny code written in 2015, 
and some of it does have to interoperate with the outside world.


And here's the list gone from LibreSSL, from what I can tell:

MD2, MDC2, RC5, SEED

Neither have removed CAST, and there is presumably a good reason for 
that. (PGP?)


It seems to me that these can pretty safely go:

MD2 - (The argument that someone somewhere may want to keep verifying 
old MD2 signatures on self-signed certs doesn't seem lik

Re: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates

[Jayalakshmi bhat]

Hi Matt,

Thank you for the response. I have attached the certificates details. My
apology I am not supposed to share the certificates. We are not using
X509_VERIFY_PARAM_xxx
API's. We are using 4 certificates with the device.

1. Root CA- Baltimore CyberTrust Root
2. Intermediate CA-1 - Microsoft Internet Authority
3. Intermediate CA-2 - Microsoft IT SSL SHA2
4. ID certificate - *.sharepoint.com

Intermediate CAs are issued by the above Root CA. Issue is seen when all 4
certificates are installed. Error happens with the intermediate CA-2.
check_trust returns X509_TRUST_UNTRUSTED. However if I do not install
intermediate CA-2 things works fine.

Any help is well appreciated.

Regards
Jayalakshmi

On Mon, Nov 16, 2015 at 2:52 PM, Matt Caswell  wrote:

>
>
> On 16/11/15 06:52, Jayalakshmi bhat wrote:
> > Hi Victor,
> >
> > Thanks a lot for details explanation.
> >
> > Our device acts as TLS/SSL client.  The device receives chain of
> > certificates as part of SSL handshake, when it is trying to get
> > connected to TLS/SSL server like sharepoint 365.
> >
> > While validating the certificate chain from server, "*check_trust"
> > *fails with X509_V_ERR_CERT_UNTRUSTED.
> >
> > This had been working fine with OpenSSL 1.0.1c.
> >
> > When I checked the code execution, check_trust was not being called  in
> > OpenSSL 1.0.1c as "if (param->trust > 0)" was not satisfied.
> >
> > That is why I wanted to know is it mandatory for the applications to
> > set X509_VERIFY_PARAM in X509_STORE_CTX
>
>
> Are you able to share the certificates that the server provides you
> with? Also the root certificate you are using.
>
> It is not mandatory to set X509_VERIFY_PARAMs (but typically you at
> least want to verify the hostname through a call to
> "X509_VERIFY_PARAM_set1_host"). Are you currently do anything like this?
>
> Matt
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
ID CERTIFICATE
Version 3 
Serial Number   4F 5D 8E A9 00 01 00 00 D8 6F  
Signature Algorithm sha1RSA 
Issuer  DC=com
DC=microsoft
DC=corp
DC=redmond
CN=MSIT Machine Auth CA 2
Valid From  4/14/2014 10:01:07 PM UTC 
Valid To4/13/2016 10:01:07 PM UTC 
Subject C=US
S=WA
L=Redmond
O=Microsoft
CN=*.sharepoint.com
Public Key 
Public Key AlgorithmRSA 
Public Key Length   2048 bits 
Exponent65537 (10001) 
Extensions 
Authority Key IdentifierKeyID=EB DB 11 5E F8 09 9E D8 D6 62 9C 
FD 62 9D E3 84 4A 28 E1 27  
Subject Key Identifier  F5 D0 5C 03 01 C3 D9 31 56 24 3F BF 26 
4F 04 A7 D8 3C B3 CE  
Basic Constraints  
Key Usage   Data Encipherment (b0), Digital 
Signature, Key Encipherment (a0) 
Extended Key Usage  Client Authentication, Server 
Authentication 
Additional Extensions   Subject Alternative Name, CRL 
Distribution Points 
Subject Alternative Name*.sharepoint.com
*.sharepoint.apac.microsoftonline.com
*.sharepoint.emea.microsoftonline.com
*.sharepoint.microsoftonline.com
Thumbprint  3D A0 FF 58 AF 96 A0 BE 01 BB 7E 05 65 
7C D7 89 27 F9 52 98  

INTERMEDIATE CA-1

Version 3 
Serial Number   07 27 6F AE  
Signature Algorithm sha1RSA 
Issuer  C=IE
O=Baltimore
OU=CyberTrust
CN=Baltimore CyberTrust Root
 
Valid From  4/25/2012 5:41:36 PM UTC 
Valid To4/25/2020 5:40:55 PM UTC 
Subject CN=Microsoft Internet Authority
Public Key 
Public Key AlgorithmRSA 
Public Key Length   4096 bits 
Exponent65537 (10001) 
Extensions 
Authority Key IdentifierKeyID=E5 9D 59 30 82 47 58 CC AC FA 08 
54 36 86 7B 3A B5 04 4D F0  
Subject Key Identifier  2A 4D 97 95 5D 34 7E 9D B6 E6 33 BE 9C 
27 C1 70 7E 67 DB C1  
Basic Constraints   critical CA: True 
Key Usage   Certi

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Emilia Käsper]

One more time,

I know that someone, somewhere is probably using any given feature of
OpenSSL. I am looking to gather information about concrete, actively
maintained applications that may be using one of those algorithms, to build
a more complete picture.

If you are aware of a concrete use of MD2 or any of the other algorithms,
please let us know!

Thanks,
Emilia

On Mon, Nov 16, 2015 at 7:25 PM, Hubert Kario  wrote:

> On Monday 16 November 2015 16:51:10 Emilia Käsper wrote:
> > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves
> >
> > This isn't of course entirely representative of widespread usage.
> > However Google's multi-billion line codebase now builds against
> > BoringSSL and therefore largely does not depend on these algorithms.
> > Those billions of lines aren't all new and shiny code written in
> > 2015, and some of it does have to interoperate with the outside
> > world.
> >
> > And here's the list gone from LibreSSL, from what I can tell:
> >
> > MD2, MDC2, RC5, SEED
> >
> > Neither have removed CAST, and there is presumably a good reason for
> > that. (PGP?)
> >
> > It seems to me that these can pretty safely go:
> >
> > MD2 - (The argument that someone somewhere may want to keep verifying
> > old MD2 signatures on self-signed certs doesn't seem like a
> > compelling enough reason to me. It's been disabled by default since
> > OpenSSL 1.0.0.) MDC2
> > SEED
> > RC5
> >
> > These could probably stay (C only):
> >
> > CAST
> > IDEA
> > RIPEMD (used in Bitcoin?)
> > WHIRLPOOL
> >
> > as well as
> >
> > BLOWFISH
> > MD4
> > RC2
> >
> > I am on the fence about the binary curves: I am not aware of any
> > usage, really, and it's not about to pick up now.
>
> I'm afraid you're too focused on TLS/SSL use case. And while it is
> important it's not the only use case the OpenSSL does serve.
>
> And for what it's worth, I'm very much *for* removing as much (and as
> fast as possible) support for the old junk (or unused stuff - like
> curves < 256 bit) in TLS. Search the archives for "Insecure DEFAULT
> cipher set" for an example.
>
> But stuff like this:
>
> > The argument that someone somewhere may want to keep verifying
> > old MD2 signatures on self-signed certs
>
> is not true. I was talking about document signatures, time stamps, CRL
> signatures and certificate signatures in general. Not the trust anchors
> or their self-signatures.
>
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Richard Moore]

On 16 November 2015 at 19:05, Hubert Kario  wrote:

> Example: CAdES V1.2.2 was published in late 2000, the first serious
> attacks on MD2 were not published until 2004. I think it is not
> unreasonable for CAdES-A documents to exist today which were originally
> signed with MD2 while it was still considered secure and that are still
> relevant today, just 15 years later.
>
>
​This doesn't explain why the code needs to exist in future versions of
openssl. The previous ones aren't going to vanish and can be compiled and
used to rescue data in theoretical edge cases like this. You're making it
sound like this is making the data totally inaccessible which is not the
case.

Cheers

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

Re: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates

[E T]

Could it be because your CA-2 has the following: Extended Key Usage - Client 
Authentication, Server Authentication?

Some fields that in general only apply to end certificates, e.g. name 
constraints, when used in a CA certificate, are interpreted as constraints on 
the certificates that can be issued by that CA.

  Erik Tkal




On Nov 16, 2015, at 11:48 AM, Jayalakshmi bhat  
wrote:

Hi Matt,

Thank you for the response. I have attached the certificates details. My 
apology I am not supposed to share the certificates. We are not using 
X509_VERIFY_PARAM_xxx API's. We are using 4 certificates with the device.

1. Root CA- Baltimore CyberTrust Root
2. Intermediate CA-1 - Microsoft Internet Authority
3. Intermediate CA-2 - Microsoft IT SSL SHA2
4. ID certificate - *.sharepoint.com 

Intermediate CAs are issued by the above Root CA. Issue is seen when all 4 
certificates are installed. Error happens with the intermediate CA-2. 
check_trust returns X509_TRUST_UNTRUSTED. However if I do not install 
intermediate CA-2 things works fine.

Any help is well appreciated.

Regards
Jayalakshmi

On Mon, Nov 16, 2015 at 2:52 PM, Matt Caswell mailto:m...@openssl.org>> wrote:


On 16/11/15 06:52, Jayalakshmi bhat wrote:
> Hi Victor,
>
> Thanks a lot for details explanation.
>
> Our device acts as TLS/SSL client.  The device receives chain of
> certificates as part of SSL handshake, when it is trying to get
> connected to TLS/SSL server like sharepoint 365.
>
> While validating the certificate chain from server, "*check_trust"
> *fails with X509_V_ERR_CERT_UNTRUSTED.
>
> This had been working fine with OpenSSL 1.0.1c.
>
> When I checked the code execution, check_trust was not being called  in
> OpenSSL 1.0.1c as "if (param->trust > 0)" was not satisfied.
>
> That is why I wanted to know is it mandatory for the applications to
> set X509_VERIFY_PARAM in X509_STORE_CTX


Are you able to share the certificates that the server provides you
with? Also the root certificate you are using.

It is not mandatory to set X509_VERIFY_PARAMs (but typically you at
least want to verify the hostname through a call to
"X509_VERIFY_PARAM_set1_host"). Are you currently do anything like this?

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


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

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

Re: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates

[Jakob Bohm]

Probably not, that constraint is satisfied since this is SSL/TLS and the 
end cert has that same EKU.


On 16/11/2015 22:37, E T wrote:
Could it be because your CA-2 has the following: Extended Key Usage 
- Client Authentication, Server Authentication?


Some fields that in general only apply to end certificates, e.g. name 
constraints, when used in a CA certificate, are interpreted as 
constraints on the certificates that can be issued by that CA.



On Nov 16, 2015, at 11:48 AM, Jayalakshmi bhat 
mailto:bhat.jayalaks...@gmail.com>> wrote:


Hi Matt,

Thank you for the response. I have attached the certificates details. 
My apology I am not supposed to share the certificates. We are not 
using X509_VERIFY_PARAM_xxx API's. We are using 4 certificates with 
the device.


1. Root CA- Baltimore CyberTrust Root
2. Intermediate CA-1 - Microsoft Internet Authority
3. Intermediate CA-2 - Microsoft IT SSL SHA2
4. ID certificate - *.sharepoint.com 

Intermediate CAs are issued by the above Root CA. Issue is seen when 
all 4 certificates are installed. Error happens with the intermediate 
CA-2. check_trust returns X509_TRUST_UNTRUSTED. However if I do not 
install intermediate CA-2 things works fine.


Any help is well appreciated.

Regards
Jayalakshmi

On Mon, Nov 16, 2015 at 2:52 PM, Matt Caswell > wrote:




On 16/11/15 06:52, Jayalakshmi bhat wrote:
> Hi Victor,
>
> Thanks a lot for details explanation.
>
> Our device acts as TLS/SSL client.  The device receives chain of
> certificates as part of SSL handshake, when it is trying to get
> connected to TLS/SSL server like sharepoint 365.
>
> While validating the certificate chain from server, "*check_trust"
> *fails with X509_V_ERR_CERT_UNTRUSTED.
>
> This had been working fine with OpenSSL 1.0.1c.
>
> When I checked the code execution, check_trust was not being
called  in
> OpenSSL 1.0.1c as "if (param->trust > 0)" was not satisfied.
>
> That is why I wanted to know is it mandatory for the applications to
> set X509_VERIFY_PARAM in X509_STORE_CTX


Are you able to share the certificates that the server provides you
with? Also the root certificate you are using.

It is not mandatory to set X509_VERIFY_PARAMs (but typically you at
least want to verify the hostname through a call to
"X509_VERIFY_PARAM_set1_host"). Are you currently do anything like
this?




Enjoy

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

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

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Matt Caswell]

On 16/11/15 15:51, Emilia Käsper wrote:
> Thanks all for your feedback!
> 
> I asked for mainstream use-cases for algorithms whose removal could
> cause widespread pain. Some individual users, undoubtedly, will be hit
> by this, and I acknowledge that they may not be reading this list. But I
> wanted to know if I'd missed something endemic. I also asked elsewhere:
> Adam Langley pointed me to the MD4 use-case and Steve confirmed that RC2
> must stay.
> 
> There is a tradeoff: by attempting to accommodate every single use-case,
> we will weaken the library for a substantial amount of our user base, by
> offering them bad defaults, or simply by virtue of the fact that our
> developer resources are not infinite. (Near)-dead code is a liability.

We can significantly reduce that liability by removing any assembler
optimisations. Also just because something is available doesn't mean it
has to be "default". We can have good defaults whilst keeping old crypto.


> 
> So far, excluding suspicions that something may be used somewhere, I've
> received one clear argument, for RC5. And, while I'm sympathetic to the
> cause, I believe this is the case where we have to balance one user's
> needs against everyone else's.
> 
> As for specific deprecation strategies:
> - Don't forget that all applications will have to recompile against 1.1.
> 
> - Disabling algorithms doesn't work well for us as it's just pushing the
> decision on the distros. It also wouldn't win us any resources as we'd
> still be responsible for keeping the code bug-free. The only win would
> be in default compiled code size.

Disabling algorithms isn't the right answer IMO. I do like the idea of a
"liblegacycrypto". That way people that only have need of current
up-to-date crypto can stick with the main library. Others who need the
older crypto can still get at it. Yes, that means we still have to
maintain this code - but I don't see it as that big a burden.

> 
> - We can leave OPENSSL_NO_XXX defines around so wrapper libraries
> (Python, PHP etc) who correctly account for the fact that an
> implementation may be missing (which they have to, anyway) will continue
> to work.
> 
> - Removing assembly support is a GREAT suggestion to simplify the
> complexity, and I think we should do this for anything we end up leaving
> in, and perhaps even for some things not yet on the hit list (RC4?).
> 
> - I appreciate OpenSSL's role as a "Swiss army knife" research tool but
> research needs shouldn't prevail over those of real applications. We are
> generally not on the frontline of deprecating things - RC4 isn't yet on
> the list. SSLv3 isn't yet on the list, etc. But we can't become the
> Internet Archive of All Old Crypto either, and there's some cleanup to
> do that's long overdue.

Being the "swiss army knife" is no bad thing (even where that includes
old crypto). We just have to find a way to separate the two concerns:
current crypto (and only current crypto) for most (and probably most
importantly for libssl users); broader crypto support for those that
want it (which is why I like the liblegacycrypto idea because it enables
us to do that).


> It seems to me that these can pretty safely go:
> 
> MD2 - (The argument that someone somewhere may want to keep verifying
> old MD2 signatures on self-signed certs doesn't seem like a compelling
> enough reason to me. It's been disabled by default since OpenSSL 1.0.0.)
> MDC2
> SEED
> RC5 

All candidates for liblegacycrypto IMO rather than deletion.

Whether this is the right thing to do in the 1.1.0 timeframe is another
consideration though. Viktor's arguments are quite convincing.

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

Re: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates

[Jakob Bohm]

At most one of CA-1 and CA-2 would be part of the chain from Baltimore 
to the end cert.


However your end cert (apparently for hosted Sharepoint services) was 
issued by a 3rd MSIT CA that was not provided.  If it wasn't provided to 
the code either, the chain would not validate for that reason alone.


I also note that none of the certs in the chain contain any Authority 
Information Access (AIA) extension (issuer certificate download URL and 
OCSP URL) only a CRL URL extension, which wouldn't be normal MS practice 
(Certificate revocation cannot be detected by some browsers that use 
only OCSP and the automatic certificate download done by some Microsoft 
Windows Security Support Providers (such as CredSSP) won't work).


Oh and you are not posting from an official Microsoft e-mail address either.

Something seems very odd here.

On 16/11/2015 17:48, Jayalakshmi bhat wrote:

Hi Matt,

Thank you for the response. I have attached the certificates details. 
My apology I am not supposed to share the certificates. We are not 
using X509_VERIFY_PARAM_xxx API's. We are using 4 certificates with 
the device.


1. Root CA- Baltimore CyberTrust Root
2. Intermediate CA-1 - Microsoft Internet Authority
3. Intermediate CA-2 - Microsoft IT SSL SHA2
4. ID certificate - *.sharepoint.com 

Intermediate CAs are issued by the above Root CA. Issue is seen when 
all 4 certificates are installed. Error happens with the intermediate 
CA-2. check_trust returns X509_TRUST_UNTRUSTED. However if I do not 
install intermediate CA-2 things works fine.


Any help is well appreciated.

Regards
Jayalakshmi

On Mon, Nov 16, 2015 at 2:52 PM, Matt Caswell > wrote:




On 16/11/15 06:52, Jayalakshmi bhat wrote:
> Hi Victor,
>
> Thanks a lot for details explanation.
>
> Our device acts as TLS/SSL client.  The device receives chain of
> certificates as part of SSL handshake, when it is trying to get
> connected to TLS/SSL server like sharepoint 365.
>
> While validating the certificate chain from server, "*check_trust"
> *fails with X509_V_ERR_CERT_UNTRUSTED.
>
> This had been working fine with OpenSSL 1.0.1c.
>
> When I checked the code execution, check_trust was not being
called  in
> OpenSSL 1.0.1c as "if (param->trust > 0)" was not satisfied.
>
> That is why I wanted to know is it mandatory for the applications to
> set X509_VERIFY_PARAM in X509_STORE_CTX


Are you able to share the certificates that the server provides you
with? Also the root certificate you are using.

It is not mandatory to set X509_VERIFY_PARAMs (but typically you at
least want to verify the hostname through a call to
"X509_VERIFY_PARAM_set1_host"). Are you currently do anything like
this?



Enjoy

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

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

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Salz, Rich]

Ø  If you are aware of a concrete use of MD2 or any of the other algorithms, 
please let us know!

Also, note that we have an extended alpha and-beta test period, so we can add 
things back if mistakes are made.

/r$

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