t 0 depth lookup:certificate has expired
OK
../certs/demo/pca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN
= Test PCA (1024 bit)
error 18 at 0 depth lookup:self signed certificate
C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test PCA (1024 bit)
error 10 at 0 depth lookup:ce
I used the asn1parse command [thanks Dave!] and while the key looks "old style"
it parses as follows:
50:d=4 hl=2 l= 8 prim: OBJECT:des-ede3-cbc
Which appears to equate to: des-ede3-cbc Three key triple DES EDE in CBC
mode
The full asn parse is:
---
0:d=0 hl=4 l=2446 c
On Mon, Sep 08, 2014 at 08:14:32PM -0700, Liz Fall wrote:
> I am trying to connect to a MongoDB SSL-enable database. This is the API:
> // only really need a PEM on the server side
> mongo::sslGlobalParams.sslPEMKeyFile = "";
The comment is highly misleading. PEM is a "meta" format. I
Viktor and all:
Thanks for your response.
I am trying to connect to a MongoDB SSL-enable database. This is the API:
#include "mongo/util/net/ssl_options.h"
#include "mongo/client/init.h"
int main() {
sslGlobalParams.sslMode.store(SSLGlobalParams::SSLMode_requireSSL);
// only re
This may indeed be the problem, but some of the changes in 1.0.2 do not
easily merge back to 1.0.1i. Specifically, this diff seems to have no
equivalent code to merge into in 1.0.1i.
We may need to consider reverting back to 1.0.1h until 1.0.2 is released.
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib
On Mon, Sep 08, 2014 at 07:44:56PM -0700, Liz Fall wrote:
> This is what my cert looks like below: What are you saying I should do?
> Thanks for the clarification.
These are the certificates for an intermediate CA and the issuing root
CA. Generally, you'd append these to a certificate file with
Hi Dave,
Thanks for your response. I am running this on Linux.
This is what my cert looks like below: What are you saying I should do?
Thanks for the clarification. Liz
-BEGIN CERTIFICATE-
MIIFrDCCBJSgAwIBAgIEQLJp/DANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMCVVMxFDASBgNV
BAoTC1dlbGxzIEZhcm
For the legacy formats (dashes-BEGIN PRIVATE RSA KEY or PRIVATE EC KEY)
just look on the DEK-Info: header line.
For PKCS#8 format (dashes-BEGIN ENCRYPTED PRIVATE KEY) do
openssl asn1parse and.
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf O
> From: owner-openssl-us...@openssl.org On Behalf Of Viktor Dukhovni
> Sent: Monday, September 08, 2014 08:42
> On Sun, Sep 07, 2014 at 07:26:05PM -0700, Liz Fall wrote:
>
> > I have checked and verified that there is no whitespace. Also, the
BEGIN
> > and END statements look correct. However,
On Mon, Sep 08, 2014 at 05:41:13PM -0700, Norm Green wrote:
> Thanks Viktor. I did get some fixes (via this list) from Steve a while back
> because SRP authenication was completely broken out of the box with 1.0.1i.
> However I don't know if all the changes in the commit you mentioned have
> been m
Thanks, Viktor.
I have tried to rewrap this cert to 64 per line, but am having difficulties.
I tried to do it in two steps with the first cert and then the second cert,
but each time, I am not getting all of the characters. Can you please help?
Thanks,
Liz
-Original Message-
From: owner
>
> No complaints from me for 1K or 2K, but...
Oh, sorry, this would be 1.0.2 and HEAD only. Not 1.0.1 or earlier.
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
:��I"Ϯ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �
Hi Viktor,
Thanks for your response.
I also saw this response from -M. Would this be a problem also?
Cert file or key file? The error indicates that the client can't find the
private key.
Thank you,
Liz
-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us.
Well, as I said, given my reading of the code, the newest version of EasyRSA
[line 861] shows the following:
local crypto="-des3"
It's in the set_pass function. [On further review of the code, this appears to
only be used by the "set-rsa-pass" or "set-ec-pass" functions, and I can't
determine w
Thanks Viktor. I did get some fixes (via this list) from Steve a while
back because SRP authenication was completely broken out of the box with
1.0.1i.However I don't know if all the changes in the commit you
mentioned have been merged. I will investigate further.
Norm
On 9/8/14 17:30,
On Mon, Sep 08, 2014 at 03:10:47PM -0700, Norm Green wrote:
> I will try to capture traffic in the next run.
Looking at the commit history after 1.0.1i, I think
you want:
commit 30fbe92c78981a417718bcbf25d295d16c5b7ed9
Author: Dr. Stephen Henson
Date: Fri Aug 8 11:24:25 2014 +0100
Fix SR
On Mon, Sep 08, 2014 at 05:03:58PM -0700, Liz Fall wrote:
> Thank you so much for your response.
>
> Do I need to request for a specific certificate that will is base64?
No, you can just re-wrap the base64 data you have to 64 characters
per line. There are two different 64's here. The size of
Hi Viktor,
Thank you so much for your response.
Do I need to request for a specific certificate that will is base64?
Thanks,
Liz
-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Viktor Dukhovni
Sent: Monday, September 08, 201
On Mon, Sep 8, 2014 at 5:59 PM, Salz, Rich wrote:
> We are considering changing the default keysize (RSA, DSA, DH) from 1K to
> 2K, and changing the default signing digest from SHA-1 to SHA-256.
No complaints from me for 1K or 2K, but...
$ cd openssl-1.0.1i
$ grep -R 512 * | grep -v -i sha
...
a
We've updated the roadmap, https://www.openssl.org/about/roadmap.html with
information about our progress on the RT backlog:
Update (8th September 2014): we have made a great deal of progress on
the backlog. A graph of ticket activity[1] is available, as is the raw data[2]
for every bug
No objection at all. Perhaps it might be worth checking that the other
defaults are sane too at the same time though. e.g. x509 versions etc.
Rich.
On 8 September 2014 22:59, Salz, Rich wrote:
> We are considering changing the default keysize (RSA, DSA, DH) from 1K to
> 2K, and changing the de
We are considering removing weak cryptography from the value of DEFAULT. That
is, append ":!LOW:!EXPORT"
It is currently defined as this in include/openssl/ssl.h:
#define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2"
Please let us know if you have strong objections to this.
-
2014-09-08 19:46 GMT+02:00 Alok Sharma :
> One thing I observerd by looking into scp
> code that it does not use SSL provided APIs (i.e.SSL_Read or SSL_Write) but
> they use it differenly i.e. might be directly calling encryption APIs and
> writing data to sockets. But I don't have much understandi
2014-09-08 16:29 GMT+02:00 Salz, Rich :
> The extern "C" makes it difficult to put things into a namespace. You'd
> either have to write class declarations that used NO public openssl header
> files in their public declaration, or we'd have to change the extern "C"
> wrappers to be something li
Hi Viktor,
From the server:
(gdb) p s->session[0]
$1 = {ssl_version = 770, key_arg_length = 0, key_arg =
"\000\000\000\000\000\000\000", master_key_length = 48,
master_key =
"\000Eθ\371\266\225\202\062\370\336x\324*\251\016\336\344\372\221\302\031\002\351\322Zk\373G\342x\273u\274|\210\362\36
On Mon, Sep 08, 2014 at 02:36:20PM -0700, Norm Green wrote:
> Thanks Victor. I don't have a handshake recording for these stacks. The
> problem occurs intermittently.
Any chance you can capture enough sessions to also nab one (full-size
packet capture) that ran into the problem?
> I've dumped
We are considering changing the default keysize (RSA, DSA, DH) from 1K to 2K,
and changing the default signing digest from SHA-1 to SHA-256.
We've already committed this to HEAD/master. We would like to make this change
in the upcoming 1.0.2 release as well. Several downstream distributions, su
Thanks Victor. I don't have a handshake recording for these stacks.
The problem occurs intermittently. I've dumped the SSL state and method
objects for the server and client. Anything else you want to see while
the processes are still alive?
Norm
Here's the SSL state and method from the
On Mon, Sep 08, 2014 at 11:16:46PM +0530, Alok Sharma wrote:
> while ( (n = read(fd, recvBuff, sizeof(recvBuff)-1)) > 0)
> {
> recvBuff[n] = 0;
> mode=n;
> i=0;
> while(mode>0)
> {
> len=SSL_write(ssl, recvBuff, mode);
>
On Mon, Sep 08, 2014 at 11:45:59AM -0700, Norm Green wrote:
> Were are occasionally seeing hangs when establishing an SSL connection with
> OpenSSL 1.0.1i. This connection uses SRP and both the server and the client
> sockets are in blocking mode (thus the hang).
>
> Is there anything I can do t
I think it's safe to assume that 3DES is almost certainly a lousier choice
than AES or Camellia on multiple fronts.
Two key triple DES provides about 80-bits of security, and three key triple
DES provides 112-bits of security. Do you know which they are using?
AES-128 provides about 128-bits of se
Continuing top posting. [Which doesn't bother me nearly as much as it seems to
bother others... ]
Yes! That was a fantastic answer.
...
[A while later]
So, I need to run this down, but it looks like the easy-rsa script uses 3DES to
do encryption - which seems incredibly foolish when we have a
Were are occasionally seeing hangs when establishing an SSL connection
with OpenSSL 1.0.1i. This connection uses SRP and both the server and
the client sockets are in blocking mode (thus the hang).
Is there anything I can do to debug this problem?
Client side:
gdb) where
#0 0x7f91e412dd
Hi,
I am trying with simple client server model where it is reading datat
from a file and calling SSL_write and similar thing is happening on other
end i.e. reading from SSL using SSL_read and writing to file. Itis taking
40 mins of time to copy file of size 600 MB and if I run a non-ssl clie
2014-09-08 18:35 GMT+02:00 Kyle Hamilton :
> The allocated buffer needs to be sizeof(char *). What's happening is the
> address of the buffer (&buffer[0]) gets written to the
> pointer-to-pointer-to-char, data. If data == NULL, you're asking to write
> the address of the buffer to unallocated memor
The allocated buffer needs to be sizeof(char *). What's happening is the
address of the buffer (&buffer[0]) gets written to the
pointer-to-pointer-to-char, data. If data == NULL, you're asking to write the
address of the buffer to unallocated memory.
It's done this way because the return value
2014-09-08 18:19 GMT+02:00 Iñaki Baz Castillo :
> This works fine:
>
> ---
> long read;
> // myBuffer is an already allocated buffer.
> char** data = (char**)&myBuffer;
>
> read = BIO_get_mem_data(bio, data);
>
> // Use data and read values.
>
> BIO_reset(bio);
> ---
2014-09-08 16:08 GMT+02:00 Richard Levitte :
> Sorry, BIO_flush() isn't what you want (it doesn't reset the buffer to
> empty), BIO_reset() is.
>
> However, you need to be careful... if I were you, I would use the
> read data before resetting, as BIO_get_mem_data() gives you the
> pointer to the i
In message
on Mon, 8 Sep 2014 15:10:04 +0200, Iñaki Baz Castillo said:
ibc> 2014-09-08 14:44 GMT+02:00 Iñaki Baz Castillo :
ibc> > --
ibc> > int read = BIO_read(sslBioToNetwork, (void*)myBuffer, MY_BUFFER_SIZE);
ibc> >
ibc> > // Use the read data
ibc> > -
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Richard Levitte
> Sent: Monday, 08 September, 2014 10:13
> To: openssl-users@openssl.org
>
> Nothing really stops us from creating a C++ namespace. After all, we
> do have the following construct in q
The extern "C" makes it difficult to put things into a namespace. You'd either
have to write class declarations that used NO public openssl header files in
their public declaration, or we'd have to change the extern "C" wrappers to be
something like
#if defined(__cplusplus) && !defined(
In message
<2a0efb9c05d0164e98f19bb0af3708c71d12a97...@usmbx1.msg.corp.akamai.com> on Mon,
8 Sep 2014 08:57:55 -0400, "Salz, Rich" said:
rsalz> > My suggestion is indeed that openssl lib switch to C++, at least for
rsalz> > namespace usage.
rsalz>
rsalz> That would be nice to have. But C++ cl
OK, that clarifies the situation and your question.
It's impossible to provide a specific answer, because private keys can be
encrypted with a variety of algorithms and key lengths. From
https://www.openssl.org/docs/apps/rsa.html:
-aes128|-aes192|-aes256|-camellia128|-camellia192|-camellia256|-
"Breaking compatibilty" with old apps will occur at a time :
dixit the roadmap :
"Review and revise the public API with a view to reducing complexity
(Timescale: Within one year)"
I suppose that reducing complexity will lead to some rewrites,
elimination/merging some functions...
So it will be
If all you want is C++ namespaces,could you you wrap the #include lines for
OpenSSL in a namespace declaration? (I am not a C++ guy, I honestly don't know
where problems would exist... except the namespaces don't do anything for
#define, I think?)
namespace openssl {
#include
};
Another alte
This is why I just mentioned "namespaces"...
Le 08/09/2014 14:57, Salz, Rich a écrit :
My suggestion is indeed that openssl lib switch to C++, at least for
namespace usage.
That would be nice to have. But C++ classes are like opinions -- everyone has
one, nobody wants to use anyone else's. :)
2014-09-08 14:44 GMT+02:00 Iñaki Baz Castillo :
> --
> int read = BIO_read(sslBioToNetwork, (void*)myBuffer, MY_BUFFER_SIZE);
>
> // Use the read data
> --
>
> with something like this:
>
> ---
> long re
On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall wrote:
> I am getting the following with my client cert when trying to connect to an
> SSL-enabled MongoDB:
>
> 2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file:
> /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem
While OpenSSL's namespace polution is certainly a problem - and a problem that
was (in general) widely discussed in the C programming community at least as
far back as the late 1980s - it's worth noting that it's a widespread issue
that affects pretty much all languages of C's generation and ear
> My suggestion is indeed that openssl lib switch to C++, at least for
> namespace usage.
That would be nice to have. But C++ classes are like opinions -- everyone has
one, nobody wants to use anyone else's. :)
I'd be surprised if OpenSSL started work on this, but I'd encourage interested
folk
There seems to be some misunderstanding :
My original answer was not directed to you, but to Kyle who was asking
for suggestions to solve your pb.
My suggestion is indeed that openssl lib switch to C++, at least for
namespace usage.
that will solve your problem with very limited -or no- impac
Hi, I'm trying to avoid a BIO_read() call given that it copies the BIO
buffer data into a buffer I must provide to the function. I use a BIO
memory pair.
In my case it would be nice if I can get the pointer and length of the
current BIO buffer and then tell the BIO to empty/clean it.
So I want to
On Sun, Sep 07, 2014 at 07:26:05PM -0700, Liz Fall wrote:
> I have checked and verified that there is no whitespace. Also, the BEGIN
> and END statements look correct. However, each line in the cert is 76 chars
> in length, except for the last line. Should the lines be 64-characters
> long?
Ye
2014-09-08 3:52 GMT+02:00 Jakob Bohm :
> And how would you do that without breaking compatibility with every
> program (in C, C++ or any other language) that already uses openssl and
> depends on the current API names?
That's the show-stopper rationale. I expect that old projects relying
on OpenSS
2014-09-08 1:15 GMT+02:00 Pierre DELAAGE :
> Switch strongly and definitely to C++
> Not for fancy object programming, but for more practical syntaxES for things
> like this.
I do code in C++, but I need some C libraries. Regardless my C++ code
is properly "namespaced" I don't like to see so m
2014-09-08 0:04 GMT+02:00 Kyle Hamilton :
> To meet the goal of interoperability while enabling an alternate symbolic
> namespace, what would you suggest?
Not a big expert in these subjects, but a workaround coming to my mind
is the following:
- Prefix ALL the OpenSSL symbols with the "OPENSSL_"
On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall wrote:
> I am getting the following with my client cert when trying to connect to
> an SSL-enabled MongoDB:
>
>
> 2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file:
> /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem
On Sun, Sep 7, 2014 at 7:15 PM, Pierre DELAAGE wrote:
> Hmm...
> Switch strongly and definitely to C++
> Not for fancy object programming, but for more practical syntaxES for things
> like this.
>
> And I am an old C fan programmer...
+1.
C really needs namespaces to avoid collisions and try/
58 matches
Mail list logo
