Re: [openssl-users] Alert number 43
Hi Jeff, I am not sure I can post the entire cert here. Is there any part in particular that would be useful to debug the Alert Number 43 problem? David On Tue, Nov 1, 2016 at 8:07 PM, Jeffrey Walton wrote: >> When I tested a remote server using s_client, it responded with: >> >> verify return:1 >> >> 139790582232992:error:14094413:SSL routines:SSL3_READ_BYTES:sslv3 >> alert unsupported certificate:s3_pkt.c:1259:SSL alert number 43 >> >> 139790582232992:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl >> handshake failure:s3_pkt.c:598: >> >> >> I found the the following URL about this: >> >> http://stackoverflow.com/questions/14435839/ssl-alert-43-when-doing-client-authentication-in-ssl?answertab=oldest#tab-top >> >> My question: Does this indicate something wrong with server side >> certificate like the URL said? > > Netscape Cert Type was recently removed, IIRC. > > OpenSSL servers [used to?] have a bug where they can't use the EC key > pair they generated for use with an EC-based certificate. Also see > http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography#Named_Curves. > > Post the certificate. Use `openssl s_client -connect : > -tls1 -servername | openssl x509 -text -noout` > > Jeff > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Alert number 43
Hi, When I tested a remote server using s_client, it responded with: verify return:1 139790582232992:error:14094413:SSL routines:SSL3_READ_BYTES:sslv3 alert unsupported certificate:s3_pkt.c:1259:SSL alert number 43 139790582232992:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598: I found the the following URL about this: http://stackoverflow.com/questions/14435839/ssl-alert-43-when-doing-client-authentication-in-ssl?answertab=oldest#tab-top My question: Does this indicate something wrong with server side certificate like the URL said? Thanks. David -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Strange problem in using verify command
Hi Jakob, The computer has been up running for quite a while. I wonder if it really needs NTP to take that long to sync up. David On Thu, Sep 10, 2015 at 7:20 PM, Jakob Bohm wrote: > On 11/09/2015 02:13, David Li wrote: >> >> Hi, >> >> I am using "openssl verify -CAfile " to verify the >> certificate. It's been running as expected. >> >> Recently I started to run this command on a different x86 platform. >> What I found is the the first few times I always got: >> >> error 9 at 1 depth lookup:certificate is not yet valid >> >> Then I waited 10 min and reran the same cmd and got "OK". >> >> I am puzzled by this. Is this a some timing issue? > > Chances are that the clock on the computer was wrong until > NTP corrected it from the network. >> >> >> My openssl version is: >> >> OpenSSL 1.0.1e-fips 11 Feb 2013 > > That's kind of old. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. http://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 ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Strange problem in using verify command
Hi, I am using "openssl verify -CAfile " to verify the certificate. It's been running as expected. Recently I started to run this command on a different x86 platform. What I found is the the first few times I always got: error 9 at 1 depth lookup:certificate is not yet valid Then I waited 10 min and reran the same cmd and got "OK". I am puzzled by this. Is this a some timing issue? My openssl version is: OpenSSL 1.0.1e-fips 11 Feb 2013 David ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to verify a cert chain using Openssl command line?
Ben, I think you are right. My verify test is okay now if I match the subjectAltName to the nameConstraints defined by the subCA. Thanks. David On Mon, Jun 29, 2015 at 6:23 PM, Ben Humpert wrote: > Yes, because nameConstraints are inherited. > > I don't know exactly where the bug lies but I strongly advise NOT to > use nameConstraints because while there is a standard nobody has > implemented full or correctly working support for it. I ran various > tests some weeks ago and the result was horrible. See > https://mta.openssl.org/pipermail/openssl-users/2015-May/001387.html > and https://mta.openssl.org/pipermail/openssl-users/2015-May/001388.html > > 2015-06-29 23:58 GMT+02:00 David Li : >> The subCA has nameConstraints in the subCA configuration file: >> >> [name_constraints] >> permitted;DNS.0 = example.com >> >> client configuration file has subjectAltName: >> subjectAltName = DNS: www.cs.com >> >> So is this a mismatch? How come s_client/s_server test was okay? >> >> >> >> >> >> On Mon, Jun 29, 2015 at 2:12 PM, Ben Humpert wrote: >>> Do you use nameConstraints or have specified IP in subjectAltName? >>> Because OpenSSL can't handle that correctly. >>> >>> 2015-06-29 22:51 GMT+02:00 David Li : >>>> Hi, >>>> >>>> As a test, I have created a rootCA, a subCA (signed by the rootCA) and >>>> a client cert (signed by the subCA). Now I want to use verify, >>>> s_client and s_server to test them together. >>>> >>>> However I searched and tried a number of times but still unsure about >>>> the correct syntax format in verify command. This is what I did: >>>> >>>> cat rootCA.crt subCA.crt > caChain.crt >>>> >>>> openssl -verbose -verify -CAflie caChain.crt clientCert.crt >>>> >>>> openssl verify -CAfile caChain.crt client/clientCert.crt >>>> client/clientCert.crt: C = US, ST = California, O = David's company, >>>> CN = David's client cert, emailAddress = david...@example.com >>>> error 47 at 0 depth lookup:permitted subtree violation >>>> >>>> >>>> However it seems my s_client and s_server test is OK: >>>> >>>> I created a caChain by cancatenating rootCA and subCA together: >>>> >>>> Server: >>>> openssl s_server -cert server/serverComb.crt -www -CAfile caChain.crt >>>> -verify 3 >>>> >>>> where serverComb.crt = cat of serverCert and server key >>>> >>>> Client: >>>> openssl s_client -CAfile caChina.crt -cert client/clientComb.crt >>>> >>>> where clientComb is = cat of clientCert and clientKey >>>> >>>> >>>> Anyone has any idea why verify command failed? >>>> >>>> Thanks. >>>> ___ >>>> openssl-users mailing list >>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> ___ >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> ___ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to verify a cert chain using Openssl command line?
The subCA has nameConstraints in the subCA configuration file: [name_constraints] permitted;DNS.0 = example.com client configuration file has subjectAltName: subjectAltName = DNS: www.cs.com So is this a mismatch? How come s_client/s_server test was okay? On Mon, Jun 29, 2015 at 2:12 PM, Ben Humpert wrote: > Do you use nameConstraints or have specified IP in subjectAltName? > Because OpenSSL can't handle that correctly. > > 2015-06-29 22:51 GMT+02:00 David Li : >> Hi, >> >> As a test, I have created a rootCA, a subCA (signed by the rootCA) and >> a client cert (signed by the subCA). Now I want to use verify, >> s_client and s_server to test them together. >> >> However I searched and tried a number of times but still unsure about >> the correct syntax format in verify command. This is what I did: >> >> cat rootCA.crt subCA.crt > caChain.crt >> >> openssl -verbose -verify -CAflie caChain.crt clientCert.crt >> >> openssl verify -CAfile caChain.crt client/clientCert.crt >> client/clientCert.crt: C = US, ST = California, O = David's company, >> CN = David's client cert, emailAddress = david...@example.com >> error 47 at 0 depth lookup:permitted subtree violation >> >> >> However it seems my s_client and s_server test is OK: >> >> I created a caChain by cancatenating rootCA and subCA together: >> >> Server: >> openssl s_server -cert server/serverComb.crt -www -CAfile caChain.crt >> -verify 3 >> >> where serverComb.crt = cat of serverCert and server key >> >> Client: >> openssl s_client -CAfile caChina.crt -cert client/clientComb.crt >> >> where clientComb is = cat of clientCert and clientKey >> >> >> Anyone has any idea why verify command failed? >> >> Thanks. >> ___ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] How to verify a cert chain using Openssl command line?
Hi, As a test, I have created a rootCA, a subCA (signed by the rootCA) and a client cert (signed by the subCA). Now I want to use verify, s_client and s_server to test them together. However I searched and tried a number of times but still unsure about the correct syntax format in verify command. This is what I did: cat rootCA.crt subCA.crt > caChain.crt openssl -verbose -verify -CAflie caChain.crt clientCert.crt openssl verify -CAfile caChain.crt client/clientCert.crt client/clientCert.crt: C = US, ST = California, O = David's company, CN = David's client cert, emailAddress = david...@example.com error 47 at 0 depth lookup:permitted subtree violation However it seems my s_client and s_server test is OK: I created a caChain by cancatenating rootCA and subCA together: Server: openssl s_server -cert server/serverComb.crt -www -CAfile caChain.crt -verify 3 where serverComb.crt = cat of serverCert and server key Client: openssl s_client -CAfile caChina.crt -cert client/clientComb.crt where clientComb is = cat of clientCert and clientKey Anyone has any idea why verify command failed? Thanks. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: SSL_MODE_SEND_FALLBACK_SCSV option
On Fri, Oct 24, 2014 at 1:28 PM, Richard Könning < richard.koenn...@ts.fujitsu.com> wrote: > Am 24.10.2014 20:47, schrieb David Li: > >> >> >> On Fri, Oct 24, 2014 at 11:18 AM, Richard Könning >> > <mailto:richard.koenn...@ts.fujitsu.com>> wrote: >> >> At 24.10.2014 19:03, David Li wrote: >> >> I am still a little unclear by what exactly TLS_FALLBACK_SCSV >> option >> would do. >> >> What if the server only supports SSLv3 + TLSv1 and client only >> connects >> with SSLv3? Without the patch, both would agree to SSLv3. So >> this is a >> problem. >> >> >> Well I thought it's the CBC cipher mode used by SSLv3 that has the >> problem. So we should avoid SSLv3 all together. >> > > Exactly. But when you have a client which speaks only SSLv3 as in your > example below you have to decide: Don't use the client or enhance it so it > speaks at least TLSv1 or use SSLv3 despite the problems with SSLv3. > > Maybe this is is my confusion. Will the SSLv3 alone cause the attack? Or >> will a "downgrade process" from TLS 1.0 or later to the SSLv3 expose the >> vulnerability? >> > > SSLv3 alone is vulnerable. When you decide that this vulnerability is so > large that you don't want to use SSLv3 in any case than life is easy: > deactivate the usage of SSLv3 in all clients and servers and you have not > to think about fall back to SSLv3. > > But when your opinion is, that an SSLv3 connection is better than no > connection than you may have to fall back to SSLv3 some times. The > TLS_FALLBACK_SCSV helps you to ensure that the fall back is done only when > SSLv3 is really the highest SSL/TLS protocol shared by client and server. > So is it true that in this case TLS_FALLBACK_SCSV still can't prevent the attack since this is a totally legitimate honest fallback to SSLv3? In other words, the MITM attacker doesn't have to message the handshake at all. > > Best regards, > Richard > > >> >> Where is the problem? When the client only supports SSLv3 and >> therefore right away starts with SSLv3, then you get an SSLv3 >> connection as wanted. When you don't want any SSLv3 connections, >> remove the SSLv3 support in the server and enhance the client so it >> speaks also TLSv1 or better. >> >> What happens with the patch only on the server? And what happens >> with >> the both server and client patched? >> >> >> First question: nothing, because the client can't say to the server >> that the second handshake with SSLv3 is a fallback of a previous >> handshake announcing the availability of TLSv1 or better. >> >> Second question: When the client starts due to a MITM attack a >> second handshake announcing SSLv3 and setting TLS_FALLBACK_SCSV >> option than the server knows that the client supports something >> better than SSLv3 and quits the handshake. >> >> Best regards, >> Richard >> >> >> >> >> On Fri, Oct 24, 2014 at 9:30 AM, Jakob Bohm >> mailto:jb-open...@wisemo.com> >> <mailto:jb-open...@wisemo.com <mailto:jb-open...@wisemo.com>>__> >> >> wrote: >> >> On 24/10/2014 18:19, Aditya Kumar wrote: >> >> Thanks Jakob for correcting my understanding. In short, >> can I >> conclude the following about FALLBACK flag. >> >> 1. Whenever client is sending the FALLBACK flag in its >> request, an >> updated Server will interpret it that this client >> supports a >> higher version but since that higher version protocol >> request was >> refused, its trying to connect using a lower version >> protocol. >> 2. The FALLBACK flag should only be set to communicate >> to those >> extremely rare old SSLv3 servers which completely fail >> to accept a >> request for (SSLv3 or TLSv1+, the best client have). In >> that case, >> first client should attempt to connect with >> SSLAUTONEGOTIATE and >> if it fails, then connect with SSLV3 FALLBACK enabled. >> >> Much simpler: The FALLBACK flag should be set only to >> comm
Re: SSL_MODE_SEND_FALLBACK_SCSV option
On Fri, Oct 24, 2014 at 11:18 AM, Richard Könning < richard.koenn...@ts.fujitsu.com> wrote: > At 24.10.2014 19:03, David Li wrote: > >> I am still a little unclear by what exactly TLS_FALLBACK_SCSV option >> would do. >> >> What if the server only supports SSLv3 + TLSv1 and client only connects >> with SSLv3? Without the patch, both would agree to SSLv3. So this is a >> problem. >> > Well I thought it's the CBC cipher mode used by SSLv3 that has the problem. So we should avoid SSLv3 all together. Maybe this is is my confusion. Will the SSLv3 alone cause the attack? Or will a "downgrade process" from TLS 1.0 or later to the SSLv3 expose the vulnerability? > > Where is the problem? When the client only supports SSLv3 and therefore > right away starts with SSLv3, then you get an SSLv3 connection as wanted. > When you don't want any SSLv3 connections, remove the SSLv3 support in the > server and enhance the client so it speaks also TLSv1 or better. > > What happens with the patch only on the server? And what happens with >> the both server and client patched? >> > > First question: nothing, because the client can't say to the server that > the second handshake with SSLv3 is a fallback of a previous handshake > announcing the availability of TLSv1 or better. > > Second question: When the client starts due to a MITM attack a second > handshake announcing SSLv3 and setting TLS_FALLBACK_SCSV option than the > server knows that the client supports something better than SSLv3 and quits > the handshake. > > Best regards, > Richard > > >> >> >> On Fri, Oct 24, 2014 at 9:30 AM, Jakob Bohm > <mailto:jb-open...@wisemo.com>> wrote: >> >> On 24/10/2014 18:19, Aditya Kumar wrote: >> >>> Thanks Jakob for correcting my understanding. In short, can I >>> conclude the following about FALLBACK flag. >>> >>> 1. Whenever client is sending the FALLBACK flag in its request, an >>> updated Server will interpret it that this client supports a >>> higher version but since that higher version protocol request was >>> refused, its trying to connect using a lower version protocol. >>> 2. The FALLBACK flag should only be set to communicate to those >>> extremely rare old SSLv3 servers which completely fail to accept a >>> request for (SSLv3 or TLSv1+, the best client have). In that case, >>> first client should attempt to connect with SSLAUTONEGOTIATE and >>> if it fails, then connect with SSLV3 FALLBACK enabled. >>> >> Much simpler: The FALLBACK flag should be set only to communicate that >> the client has activated its manual fall back code (if any). If the >> client doesn't contain manual fallback code, it doesn't need to do >> anything. >> >>> 3. Points 2 holds true even for the cases where clients connecting >>> using TLS 1.2 fail and then client need to connect using TLS 1.1, >>> TLS1.0 or SSLV3.0. Then client should attempt the next connections >>> using FALLBACK flag set. >>> >> Yes, SSLv3 is just an example, which happens to be important right now >> because of poodle. >> >>> >>> Hope this will clear all the confusions. >>> >>> -Aditya >>> >>> On Fri, Oct 24, 2014 at 5:35 PM, Jakob Bohm >> <mailto:jb-open...@wisemo.com>>wrote: >>> >>> >>> On 24/10/2014 13:33, Aditya Kumar wrote: >>> >>> Hi All, >>> >>> Thanks for your detailed responses, specially Florian >>> Weimer and Matt Caswell. For the benefit of everyone and >>> me, I am summarizing the thoughts which I have understood >>> through all your replies. Please correct me wherever I am >>> wrong. >>> >>> To summarize: >>>1. Best way to prevent POODLE attack is to disable >>> SSLV3 on both client and server side. >>> 2. If for some reason, you cannot disable SSLv3 on server >>> side even if Server support TLS 1.0 or higher(e.g server >>> having SSLV23 set), Server definitely need to be patched >>> to prevent fallback. Once server is patched, it will >>> prevent updated clients from fallback attack. >>> 3. After server is patched with OpenSSL FALLBACK flag >>> fix, Server’s behavior wi
Re: SSL_MODE_SEND_FALLBACK_SCSV option
I am still a little unclear by what exactly TLS_FALLBACK_SCSV option would do. What if the server only supports SSLv3 + TLSv1 and client only connects with SSLv3? Without the patch, both would agree to SSLv3. So this is a problem. What happens with the patch only on the server? And what happens with the both server and client patched? On Fri, Oct 24, 2014 at 9:30 AM, Jakob Bohm wrote: > On 24/10/2014 18:19, Aditya Kumar wrote: > > Thanks Jakob for correcting my understanding. In short, can I conclude > the following about FALLBACK flag. > > 1. Whenever client is sending the FALLBACK flag in its request, an > updated Server will interpret it that this client supports a higher version > but since that higher version protocol request was refused, its trying to > connect using a lower version protocol. > 2. The FALLBACK flag should only be set to communicate to those extremely > rare old SSLv3 servers which completely fail to accept a request for (SSLv3 > or TLSv1+, the best client have). In that case, first client should attempt > to connect with SSLAUTONEGOTIATE and if it fails, then connect with SSLV3 > FALLBACK enabled. > > Much simpler: The FALLBACK flag should be set only to communicate that > the client has activated its manual fall back code (if any). If the > client doesn't contain manual fallback code, it doesn't need to do > anything. > > 3. Points 2 holds true even for the cases where clients connecting using > TLS 1.2 fail and then client need to connect using TLS 1.1, TLS1.0 or > SSLV3.0. Then client should attempt the next connections using FALLBACK > flag set. > > Yes, SSLv3 is just an example, which happens to be important right now > because of poodle. > > > Hope this will clear all the confusions. > > -Aditya > > On Fri, Oct 24, 2014 at 5:35 PM, Jakob Bohm > wrote: > >> On 24/10/2014 13:33, Aditya Kumar wrote: >> >>> Hi All, >>> >>> Thanks for your detailed responses, specially Florian Weimer and Matt >>> Caswell. For the benefit of everyone and me, I am summarizing the thoughts >>> which I have understood through all your replies. Please correct me >>> wherever I am wrong. >>> >>> To summarize: >>>1. Best way to prevent POODLE attack is to disable SSLV3 on both >>> client and server side. >>> 2. If for some reason, you cannot disable SSLv3 on server side even if >>> Server support TLS 1.0 or higher(e.g server having SSLV23 set), Server >>> definitely need to be patched to prevent fallback. Once server is patched, >>> it will prevent updated clients from fallback attack. >>> 3. After server is patched with OpenSSL FALLBACK flag fix, Server’s >>> behavior will not change for the clients which do not send FALLBACK flag in >>> their clienthello request. Server will continue to work with older client >>> as usual. Only if an updated client sends FALLBACK flag into its >>> clienthello request, server will be able to prevent fallback. >>> 4. If for some reason, client has to keep SSLV3 enable even if it >>> supports TLS 1.0 or higher version, client need to patch itself and set >>> FALLBACK flag so that it does not come under fallback attack. >>> >> WRONG, See below >> >>> 5. Clients should never set protocol as SSLV23 to support both SSL3.0 >>> and TLS Servers. Clients should always explicitly first try to connect >>> using its highest supported version(TLS1.0 or higher) and if the server >>> rejects the connection, then clients should explicitly try to connect using >>> next supported lower version protocol. >>> >> WRONG, If client simply calls the SSL23_ (aka SSLAUTONEGOTIATE_) with >> options to allow both SSLv3 and higher TLSvX.XX, it is already secure >> and will never need to send the fallback flag. >> >>> 6. While connecting to server using higher protocol like TLS1 or >>> higher, client should set FALLBACK flag so that server do not allow >>> automatically downgrade to a lower version protocol. >>> >> WRONG, Client should always try its full range of enabled SSL/TLS >> versions in one attempt, in which case the protocols themselves >> (even without the latest patch) will automatically detect and >> prevent a fallback MiTM attack. >> >> However if client needs to work around some (extremely rare) old >> SSLv3 servers which completely fail to accept a request for (SSLv3 >> r TLSv1+, the best you have), that client may use a workaround of: >> >> Step 6.1: Attempt to connect with SSLAUTONEGOTIATE_(SSLv3 up to >> TLSv1.2). Do not set/send FALLBACK flag. >> >> Step 6.2: If Step 6.1 fails (either because of old broken server or >> because of new fallback MiTM attack), try again with SSLV3ONLY_(), >> and set the FALLBACK flag to tell the server that the maximum >> version specified in this call is not the true maximum version of >> the client (in case it is not an old server, but a MiTM attack >> trying to trick this fallback code). >> >> Step 6.3: Step 6.2 could be extended to do retries with TLSv1.1, >> then TLSv1.0, then SSLv3 etc. all of wh
Re: Question on EVP_DecryptFinal_ex
Hi Thulasi/Rich, Thanks! This prompted me to uncover another bug in the code. I did encrypt an extra block of zeros! Now everything makes sense. Can't help to dig a little deeper into this: In AES-CBC mode, the decryption can be paralleled. Is this what the EVP_DecryptUpdate is doing behind the scene? For example, I need to break a long string into blocks to use EVP_EncryptUpdate but I only need to feed the ciphertext into EVP_DecryptUpdate once. David On Fri, Aug 1, 2014 at 8:36 PM, Salz, Rich wrote: > Just wanted to say that Thulasi’s explanations and advice are exactly > correct; thanks! > > > > -- > > Principal Security Engineer > > Akamai Technologies, Cambridge MA > > IM: rs...@jabber.me Twitter: RichSalz > > >
Re: Question on EVP_DecryptFinal_ex
Hi Thulasi,
You are right! It's a bug on my part.
I have a follow-up question regarding what EVP_DecryptFinal is doing.
In my case, the original string is 27 bytes long, the ciphertext length
is 48 ( I am using AES-CBC-128). The decrypted plaintext before
finalization is 32 but the finalization added 11 more bytes. So the total
decrypted len is 43.
Can you explain where the 11 more bytes are coming from after finalization?
Also It seems OK even if I don't use finalization,
David
On Thu, Jul 31, 2014 at 8:22 PM, Thulasi Goriparthi <
thulasi.goripar...@gmail.com> wrote:
>
>
>
> On Fri, Aug 1, 2014 at 5:46 AM, David Li wrote:
>
>> Hi,
>>
>> I am using openssl 1.0.1h and AES128 CBC mode to encrypt some arbitrary
>> long ASCII string.
>> I encountered an issue at decryption. If I use EVP_DecryptFinal_ex then
>> the output is unrecognizable. If I remove the following then the output is
>> OK.
>>
>> if ((rc = EVP_DecryptFinal_ex(&ctx, debuf, &tmplen)) == 0) {
>> printf (" Finalization error: %d\n", rc);
>> return -1;
>> }
>>
>
> You are most probably over-writing the decrypted data you have got with
> EVP_DecryptUpdate. Skip the the length that you have already decrypted in
> debuf. i.e If you have got outlen bytes from DecryptUpdate, you should
> supply "debuf+outlen" as second argument to EVP_DecryptFinal
>
>
>> Can anyone explain why?
>>
>> David
>>
>>
>
Question on EVP_DecryptFinal_ex
Hi,
I am using openssl 1.0.1h and AES128 CBC mode to encrypt some arbitrary
long ASCII string.
I encountered an issue at decryption. If I use EVP_DecryptFinal_ex then the
output is unrecognizable. If I remove the following then the output is OK.
if ((rc = EVP_DecryptFinal_ex(&ctx, debuf, &tmplen)) == 0) {
printf (" Finalization error: %d\n", rc);
return -1;
}
Can anyone explain why?
David
Question on certificate chain creation in using SSL_CTX_use_certificate_chain_file
Hi, Say, I have a servercert.pem, serverkey.pem and cacert.pem. When using SSL_CTX_use_certificate_chain_file() to load a cert file as the second argument, I will have to construct the file like this: cat servercert.pem serverkey.pem cacert.pem > server.pem and use server.pem in the API. My question is why I need to put in the private server key when loading the certificates? What's even more confusing to me is that later on I have to use SSL_CTX_use_PrivateKey_file() to load the private key file which again is the same as server.pem. I might have misunderstood something or these two APIs might have internally picked the ones they need and ignore the rest in the file. Maybe it's just a convenient way to use a single file for both. David
Re: Openssl crashed when loading certificates
Oh, I see, I should have used SSL_library_init() rather than OPENSSL_init_library(). Thanks everyone! Great help! David On Tue, May 20, 2014 at 1:38 PM, David Li wrote: > Rich, > > I did the following calls: > > OpenSSL_add_all_algorithms(); > OPENSSL_init_library(); > SSL_load_error_strings(); > > Are these enough? > > > > > On Tue, May 20, 2014 at 1:32 PM, Richard Moore wrote: > >> On 20 May 2014 20:13, David Li wrote: >> >>> So obviously my SSL_CTX object wasn't created properly. Now I have to >>> figure out what it means by "library has no ciphers". >>> >>> >> You haven't called the functions to initialise openssl. >> >> Rich. >> >> > >
Re: Openssl crashed when loading certificates
Rich, I did the following calls: OpenSSL_add_all_algorithms(); OPENSSL_init_library(); SSL_load_error_strings(); Are these enough? On Tue, May 20, 2014 at 1:32 PM, Richard Moore wrote: > On 20 May 2014 20:13, David Li wrote: > >> So obviously my SSL_CTX object wasn't created properly. Now I have to >> figure out what it means by "library has no ciphers". >> >> > You haven't called the functions to initialise openssl. > > Rich. > >
Re: Openssl crashed when loading certificates
Dave,
Thanks for the suggestion! I took a look at the low-hanging fruit first -
my SSL ctx object. So I modified the code a little bit by checking the SSL
CTX first:
ctx = SSL_CTX_new(SSLv23_method()); // handle only SSL v2 and v3
if (!ctx) {
int_error("Error in creating SSL ctx\n");
return 0;
}
fprintf(stderr,"Loading server certificate\n");
if (SSL_CTX_use_certificate_chain_file(ctx,SERVER_CERT) != 1) {
int_error("Error loading server certificate");
}
This time it complained about:
ssl_server.c 27, Error in creating SSL ctx
139658508588992:error:140A90A1:SSL
routines:SSL_CTX_new:library has no ciphers:ssl_lib.c:1770:
So obviously my SSL_CTX object wasn't created properly. Now I have to
figure out what it means by "library has no ciphers".
David
On Tue, May 20, 2014 at 11:47 AM, Dave Thompson wrote:
> > From: owner-openssl-us...@openssl.org [mailto:
> owner-openssl-us...@openssl.org] On Behalf Of David Li
> > Sent: Tuesday, May 20, 2014 13:05
>
> > I am using SSL_CTX_use_certificate_chain_file() to load my server
> certificate files at initialization.
> > The PEM file is created by concatenating server cert, server key and CA
> cert together.
> > I used the following command line to check its format and it seemed OK.
>
> > $ openssl s_server -cert servercert.pem -www
> > Using default temp DH parameters
> > Using default temp ECDH parameters
> > ACCEPT
>
> Note s_server does use_certificate_file (and also use_PrivateKey_file) not
> the _chain_ version,
> so that really only checks that the server (first) cert and privatekey are
> good, not the rest
> of the file. However, even if the CA cert is somehow bad it should at
> worst give an error return
> (and maybe just discard it) not a SEGV. However, if the CA cert is a root
> (possibly your own
> DIY root) it doesn't matter if it's in the file and good or not, because
> servers aren't required
> to send the root of their chain -- because clients can never trust a root
> (or in general anchor)
> sent by the server and must already have it local anyway.
>
> > And I can use openssl s_client command line to connect to the above
> server without any issues.
>
> What did you use for s_client's trust store (-CAfile and/or -CApath)?
>
> > Now when I started my server, the code crashed inside the
> SSL_CTX_use_certificate_chain_file():
>
> > There wasn't any detailed errors printed out but only:Segmentation fault
> (core dumped)
>
> When you get an unhandled signal -- and SEGV usually isn't and often can't
> be handled --
> a C program aborts without outputting anything that wasn't output (and
> where applicable
> flushed) before the signal. This is unlike 'voluntary' error handling
> where the code gets
> a return value indicating an error (such as -1 from SSL_connect or NULL
> from fopen)
> and can -- and should -- print information about the problem. And unlike
> some other
> languages that (more or less reliably) catch exceptions and give details
> for them.
>
> > Can anyone suggest how to debug this issue?
>
> The same way you debug SEGV in any C program. In this case you got a core
> dump file;
> open it with the debugger of your choice -- gdb is common and popular --
> and try to
> look at the stack (bt in gdb). Sometimes the stack is clobbered by the
> same bug that
> caused the SEGV, but usually it shows where -- or nearly where -- the code
> was
> executing and called from and sometimes (often?) the function arguments at
> each level.
>
> Alternatively, (re)run the program under control of a debugger like gdb to
> start with.
> Set breakpoints before or at the call that fails, and look to make sure
> the arguments
> are good -- for use_cert_chain, ctx points to a validly allocated and
> initialized SSL_CTX
> (to a first approximation if p *ctx doesn't give a gdb error and isn't all
> zero or obvious
> garbage, it's likely okay) and *file is the correct filename (and null
> terminated).
> If they look okay and you either built openssl from source or have the
> source from which
> it was built installed, step in and see where it fails; but that's only
> needed if the bug is
> in the openssl code which is unlikely as thousands or millions of other
> people use it
> without problem. (Though not completely impossible.)
>
> Or if you don't like the debugger, try taking out parts of your code that
> don't appear
> to be related to the problem to see if it still occurs. While it does,
> keep reducing until
> you either find the problem or get to a small self-contained example t
Re: Openssl crashed when loading certificates
Dustin,
Yes, I was trying SSL_CTX_use_certificate_file to see what happened and it
still crashed. The original code looks like:
if (SSL_CTX_use_certificate_chain_file(ctx, SERVER_CERT) != 1) {
}
The manpage says:
SSL_CTX_use_certificate_chain_file() loads a certificate chain from
file into ctx. The certificates
must be in PEM format and must be sorted starting with the subject's
certificate (actual client or
server certificate), followed by intermediate CA certificates if
applicable, and ending at the highest
level (root) CA.
So that's why I used a concatenated chain of certificates: server cert -
server key - CA cert (self signed). It's strange to me that
openssl s_server command can load the same cert chain no problem. So I am
leaning towards that it's in my code not the cert chain problem.
David
On Tue, May 20, 2014 at 11:07 AM, Dustin Oprea wrote:
> On Tue, May 20, 2014 at 1:04 PM, David Li wrote:
>
>> Hi,
>>
>> I am new to openssl programming. My goal is trying to get a simple server
>> up and running. I am using OpenSSL 1.0.1e-fips 11 Feb 2013 on Centos6.5.
>>
>> I am using SSL_CTX_use_certificate_chain_file() to load my server
>> certificate files at initialization. The PEM file is created by
>> concatenating server cert, server key and CA cert together. I used the
>> following command line to check its format and it seemed OK.
>>
>> $ openssl s_server -cert servercert.pem -www
>> Using default temp DH parameters
>> Using default temp ECDH parameters
>> ACCEPT
>>
>> And I can use openssl s_client command line to connect to the above
>> server without any issues.
>>
>>
>> Now when I started my server, the code crashed inside
>> the SSL_CTX_use_certificate_chain_file():
>>
>> if (SSL_CTX_use_certificate_file(ctx, SERVER_CERT, SSL_FILETYPE_PEM) !=
>> 1) {
>> int_error("Error loading server certificate");
>> }
>>
>> There wasn't any detailed errors printed out but only:Segmentation fault
>> (core dumped)
>>
>> I searched the old mailing list and on the web but found no clues so far.
>>
>> Can anyone suggest how to debug this issue?
>>
>>
> The code that you cited doesn't use SSL_CTX_use_certificate_chain_file.
>
> I'm new to this arena, too. However, I don't think the public-key should
> be in the trust chain. Make sure that's correct, and that you're only
> sending the one certificate into SSL_CTX_use_certificate_file.
>
>
>
> Dustin
>
>
>> Thanks.
>>
>> David
>>
>
>
Openssl crashed when loading certificates
Hi,
I am new to openssl programming. My goal is trying to get a simple server
up and running. I am using OpenSSL 1.0.1e-fips 11 Feb 2013 on Centos6.5.
I am using SSL_CTX_use_certificate_chain_file() to load my server
certificate files at initialization. The PEM file is created by
concatenating server cert, server key and CA cert together. I used the
following command line to check its format and it seemed OK.
$ openssl s_server -cert servercert.pem -www
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
And I can use openssl s_client command line to connect to the above server
without any issues.
Now when I started my server, the code crashed inside
the SSL_CTX_use_certificate_chain_file():
if (SSL_CTX_use_certificate_file(ctx, SERVER_CERT, SSL_FILETYPE_PEM) != 1)
{
int_error("Error loading server certificate");
}
There wasn't any detailed errors printed out but only:Segmentation fault
(core dumped)
I searched the old mailing list and on the web but found no clues so far.
Can anyone suggest how to debug this issue?
Thanks.
David
