Re: certificate verification problem
On 10/31/2014 03:24 PM, Dave Thompson wrote: >> From: owner-openssl-us...@openssl.org On Behalf Of tho...@koeller.dyndns.org >> Sent: Thursday, October 30, 2014 14:50 > >> I have... root_ca.pem ... self-signed ... issued host_ca.pem ... >> I would expect the two to form a valid chain. And indeed, >> verification succeeds: > >> ... openssl verify -CAfile root_ca.pem host_ca.pem >> host_ca.pem: OK > >> However, if I add -issuer_checks to the command line, I get errors: > >> openssl verify -CAfile root_ca.pem -issuer_checks host_ca.pem >> host_ca.pem: C = DE, ST = Hamburg, L = Hamburg, O = K\C3\B6ller Family, >> OU = Network Administration, CN = K\C3\B6ller Family Host Signing Certificate >> error 29 at 0 depth lookup:subject issuer mismatch >> C = DE, ST = Hamburg, L = Hamburg, O = K\C3\B6ller Family, OU = Network >> Administration, CN = K\C3\B6ller Family Host Signing Certificate >> error 29 at 0 depth lookup:subject issuer mismatch >> C = DE, ST = Hamburg, L = Hamburg, O = K\C3\B6ller Family, OU = Network >> Administration, CN = K\C3\B6ller Family Host Signing Certificate >> error 29 at 0 depth lookup:subject issuer mismatch >> OK > >> Next, I look at the subject and issuer fields of both certificates, and >> find them to be matching: >> Am I wrong to expect the verify command to succeed without errors in >> this case, even with -issuer_checks? I am attaching the two certificates, >> in case someone wants to investigate the problem. > > As the manpage says: > Print out diagnostics relating to searches for the issuer certificate of the > current certificate. > This shows why each candidate issuer certificate was rejected. The presence of > rejection messages does not itself imply that anything is wrong; during > the normal verification process, several rejections may take place. > I assumed that this applies to the case of the certificate being checked against multiple candidate issuer certificates, some of them not matching the certificate being checked. However, in my case, there is exactly one issuer certificate, and it _does_ match the one tested. > In particular, although the manpage doesn't say so, X509_verify_cert > checks several(!) times whether your cert is self-issued, only to find it > isn't, > causing the "errors" you see in this case. If verify with -issuer_checks returns errors even if there are exactly two certificates involved and the issuer matches the cert tested, then I feel tempted to say that this option is not terribly useful, because it will always report errors and will never succeed, > > The result is "OK"; the "errors" should be ignored. > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
feeds
Good morning! Please consider adding a release and - if you have time for that - a separate security alert feed. Thank you!! Szépe Viktor -- +36-20-4242498 s...@szepe.net skype: szepe.viktor Budapest, XX. kerület __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Make depend issue in Openssl-1.0.1j/ssl
Jay,
Thank you very much. Your email helped me solve my issue.
Thanks again,
Phil
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Jay Foster
Sent: Thursday, October 30, 2014 4:21 PM
To: openssl-users@openssl.org
Subject: Re: Make depend issue in Openssl-1.0.1j/ssl
I ran into this as well, but fixed it. The issue for me was my build
environment was for a cross compilation. It had some extra compiler/linker
options that caused the compiler to search the sysroot path header files
before the ones specified by -I statements. The result was the compiler
was using the OpenSSL header files from my tool chain instead of the ones in
the (latest) source. The tool chain had the previous version installed, so was
missing the TLS_MAX_VERSION definition.
Normally, -I include directives will get searched first, before any
normal system search paths. This will get the correct header files from the
source tree. If you do something like '-nostdinc -I${SYSROOT}/usr/include
-I', then the reverse will happen. Ref
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html.
Jay
On 10/30/2014 12:40 PM, Philip Bellino wrote:
Hello,
I am running in the following issue when I do a "make depend (after the
"./config shared no-ssl3"):
making depend in ssl...
make[3]: Entering directory '.../openssl-1.0.1j/ssl'
s3_lib.c:3370:4: #error Code needs update for SSLv23_method() support beyond
TLS1_2_VERSION.
d1_lib.c:274:4: #error Code needs update for DTLS_method() support beyond
DTLS1_VERSION.
make[3]: *** [depend] Error 1
In ssl/s3_lib.c, there is a new case statement in openssl-1.0.1j:
case SSL_CTRL_CHECK_PROTO_VERSION:
/* For library-internal use; checks that the current protocol
* is the highest enabled version (according to
s->ctx->method,
* as version negotiation may have changed s->method). */
if (s->version == s->ctx->method->version)
return 1;
/* Apparently we're using a version-flexible SSL_METHOD
* (not at its highest protocol version). */
if (s->ctx->method->version == SSLv23_method()->version)
{
#if TLS_MAX_VERSION != TLS1_2_VERSION
# error Code needs update for SSLv23_method() support beyond TLS1_2_VERSION.
#endif
if (!(s->options & SSL_OP_NO_TLSv1_2))
return s->version == TLS1_2_VERSION;
if (!(s->options & SSL_OP_NO_TLSv1_1))
return s->version == TLS1_1_VERSION;
if (!(s->options & SSL_OP_NO_TLSv1))
return s->version == TLS1_VERSION;
if (!(s->options & SSL_OP_NO_SSLv3))
return s->version == SSL3_VERSION;
if (!(s->options & SSL_OP_NO_SSLv2))
return s->version == SSL2_VERSION;
}
return 0; /* Unexpected state; fail closed
--
A grep -ri TLS_MAX_VERSION *
include/openssl/tls1.h:#define TLS_MAX_VERSIONTLS1_2_VERSION
ssl/s23_clnt.c:/* ensure that TLS_MAX_VERSION is up-to-date */
ssl/s23_clnt.c:OPENSSL_assert(s->version <= TLS_MAX_VERSION);
ssl/s3_lib.c:#if TLS_MAX_VERSION != TLS1_2_VERSION
ssl/tls1.h:#define TLS_MAX_VERSIONTLS1_2_VERSION
and a grep -ri DTLS_MAX_VERSION *
include/openssl/dtls1.h:#define DTLS_MAX_VERSIONDTLS1_VERSION
ssl/dtls1.h:#define DTLS_MAX_VERSIONDTLS1_VERSION
ssl/d1_lib.c:#if DTLS_MAX_VERSION != DTLS1_VERSION
ssl/d1_lib.c:return s->version == DTLS_MAX_VERSION;
This leads me to believe that the code should never have the above error
conditions occur, but in fact it is.
Any help would be most appreciated and I apologize if I am missing something in
my analysis.
Thanks,
Phil
Phil Bellino
Principal Software Engineer| MRV Communications Inc.
300 Apollo Drive | Chelmsford, MA 01824
Phone: 978-674-6870 | Fax: 978-674-6799
www.mrv.com
[MRV-email]
[Image removed by sender.
E-Banner]
The contents of this message, together with any attachments, are intended only
for the use of the person(s) to whom they are addressed and may contain
confidential and/or privileged information. If you are not the intended
recipient, immediately advise the sender, delete this message and any
attachments and note that any distribution, or copying of this message, or any
attachment, is prohibited.
[E-Banner]
RE: certificate verification problem
> From: owner-openssl-us...@openssl.org On Behalf Of tho...@koeller.dyndns.org > Sent: Thursday, October 30, 2014 14:50 > I have... root_ca.pem ... self-signed ... issued host_ca.pem ... > I would expect the two to form a valid chain. And indeed, > verification succeeds: > ... openssl verify -CAfile root_ca.pem host_ca.pem > host_ca.pem: OK > However, if I add -issuer_checks to the command line, I get errors: > openssl verify -CAfile root_ca.pem -issuer_checks host_ca.pem > host_ca.pem: C = DE, ST = Hamburg, L = Hamburg, O = K\C3\B6ller Family, > OU = Network Administration, CN = K\C3\B6ller Family Host Signing Certificate > error 29 at 0 depth lookup:subject issuer mismatch > C = DE, ST = Hamburg, L = Hamburg, O = K\C3\B6ller Family, OU = Network > Administration, CN = K\C3\B6ller Family Host Signing Certificate > error 29 at 0 depth lookup:subject issuer mismatch > C = DE, ST = Hamburg, L = Hamburg, O = K\C3\B6ller Family, OU = Network > Administration, CN = K\C3\B6ller Family Host Signing Certificate > error 29 at 0 depth lookup:subject issuer mismatch > OK > Next, I look at the subject and issuer fields of both certificates, and > find them to be matching: > Am I wrong to expect the verify command to succeed without errors in > this case, even with -issuer_checks? I am attaching the two certificates, > in case someone wants to investigate the problem. As the manpage says: Print out diagnostics relating to searches for the issuer certificate of the current certificate. This shows why each candidate issuer certificate was rejected. The presence of rejection messages does not itself imply that anything is wrong; during the normal verification process, several rejections may take place. In particular, although the manpage doesn't say so, X509_verify_cert checks several(!) times whether your cert is self-issued, only to find it isn't, causing the "errors" you see in this case. The result is "OK"; the "errors" should be ignored. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: sign data and verify it
On Fri, Oct 31, 2014 at 6:57 AM, Amir Reda wrote: > dear all i made a code for sign some data and verify it i am using eclipse > as IDE and ubuntu 13.10 i have linked eclipse with ssl lib and crypto++ > which i use in this code i got an error > > Invoking: Cross G++ Linker > g++ -L/usr/include/openssl -L/usr/include/cryptopp -L/usr/include/crypto++ > -L/usr/include -o "sign" ./src/sign.o -lssl -lcryptopp -lcrypto++ > /usr/bin/ld: ./src/sign.o: undefined reference to symbol > 'RSA_sign@@OPENSSL_1.0.0' > /lib/i386-linux-gnu/libcrypto.so.1.0.0: error adding symbols: DSO missing > from command line > collect2: ld returned 1 exit status Be sure you have the dev package installed for Ubuntu. I think that's 'sudo apt-get install libssl-dev'.(See https://packages.debian.org/search?keywords=libssl-dev). Add '-lss -lcrypto'. They are the OpenSSL libraries. Add them in the order shown. '-lcryptopp -lcrypto++' are Wei Dai's Crypto++ libraries. Are you sure you need them? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
sign data and verify it
dear all i made a code for sign some data and verify it i am using eclipse
as IDE and ubuntu 13.10 i have linked eclipse with ssl lib and crypto++
which i use in this code i got an error
Invoking: Cross G++ Linker
g++ -L/usr/include/openssl -L/usr/include/cryptopp -L/usr/include/crypto++
-L/usr/include -o "sign" ./src/sign.o -lssl -lcryptopp -lcrypto++
/usr/bin/ld: ./src/sign.o: undefined reference to symbol 'RSA_sign@
@OPENSSL_1.0.0'
/lib/i386-linux-gnu/libcrypto.so.1.0.0: error adding symbols: DSO missing
from command line
collect2: ld returned 1 exit status
what can i do i need real help
--
Warmest regards and best wishes for a good health,*urs sincerely *
*mero*
/*
* sign.cc
*
* Created on: Oct 30, 2014
* Author: amir
*/
#include "sign.h"
Sign::Sign()
{
m_rsa_keyPairs = RSA_new();
GenerateRSAPairs();
SetSharedKey();
}
Sign::~Sign()
{
RSA_free(m_rsa_keyPairs);
}
void
Sign::SetANData(int size)
{
cout<<"andata is "
