-inkey pkey.pem -out /some/file.dat
[ But see above, you have zero guarantee that the file has not
been tampered with by some with access to the non-secret public
key. ]
It is rather puzzling why it would be a problem to set some correct or
bogus 2-letter country code. It in no way c
A#) openssl req -x509 -nodes -newkey rsa:4096 -keyout private.key -out
public.key
B#) openssl smime -encrypt -binary -aes-256-cbc -in message.txt -out
encrypted.dat -outform DER public.key
C#) openssl smime -decrypt -in encrypted.dat -binary -inform DEM -inkey
private.key -out decrypted.txt
H
ryption step to work by means of the public key,
> I have found the following approach with relies on the generation of a
> Certificate Request. The problem is however, that by doing things like this,
>
> A#) openssl req -x509 -nodes -newkey rsa:16384 -keyout private.key -out
> publi
means of the public key,
I have found the following approach with relies on the generation of a
Certificate Request. The problem is however, that by doing things like this,
A#) openssl req -x509 -nodes -newkey rsa:16384 -keyout private.key -out
public.key
B#) openssl smime -encrypt -binary -aes-256
means of the public key,
I have found the following approach with relies on the generation of a
Certificate Request. The problem is however, that by doing things like this,
A#) openssl req -x509 -nodes -newkey rsa:16384 -keyout private.key -out
public.key
B#) openssl smime -encrypt -binary -aes-256
On 9/4/22 01:55, Roger James via openssl-users wrote:
As I mentioned in an earlier post you need version 1.1 or later of
openssl to successfully validate post September 30, 2021 Lets Encrypt
certificates. The version on your Centos system is 1.0.
The CentOS system was just another VM I ran the
On Sun, Sep 04, 2022 at 08:55:26AM +0100, Roger James via openssl-users wrote:
> As I mentioned in an earlier post you need version 1.1 or later of openssl
> to successfully validate post September 30, 2021 Lets Encrypt certificates.
> The version on your Centos system is 1.0.
This is not quite
As I mentioned in an earlier post you need version 1.1 or later of openssl
to successfully validate post September 30, 2021 Lets Encrypt certificates.
The version on your Centos system is 1.0.
On Sat, Sep 03, 2022 at 05:47:25PM -0600, Shawn Heisey via openssl-users wrote:
> > Post the output of:
> >
> > $ openssl crl2pkcs7 -nocrl -certfile
> > /etc/ssl/certs/local/DOMAIN.wildcards.pem |
> > openssl pkcs7 -print_certs -noout |
> > perl -ne 'BEGIN{$/="\n\n\n"} s/\n+/\n/g; print $
On 9/3/22 16:07, Viktor Dukhovni wrote:
Post the output of:
$ openssl crl2pkcs7 -nocrl -certfile
/etc/ssl/certs/local/DOMAIN.wildcards.pem |
openssl pkcs7 -print_certs -noout |
perl -ne 'BEGIN{$/="\n\n\n"} s/\n+/\n/g; print $_, "\n"'
subject=CN = DOMAIN
issuer=C = US, O = Let's Encrypt, CN =
On Fri, Sep 02, 2022 at 09:42:13PM -0600, Shawn Heisey via openssl-users wrote:
> On an AlmaLinux 8.6 VM hosted in Proxmox:
>
> [root@certs ~]# openssl verify -CAfile
> /etc/ssl/certs/local/DOMAIN.wildcards.pem
> /etc/ssl/certs/local/DOMAIN.wildcards.pem
> C = US, O = Let's Encrypt, CN = R3
> e
On 3 September 2022 19:26:50 Shawn Heisey via openssl-users
wrote:
On 9/2/22 21:42, Shawn Heisey via openssl-users wrote:
Other bare metal systems and their results with the same PEM file:
Verifies on Proxmox (the one running the VM) with openssl 1.1.1n
Verifies on Ubuntu 22.04 with ope
On 3 September 2022 19:26:50 Shawn Heisey via openssl-users
wrote:
On 9/2/22 21:42, Shawn Heisey via openssl-users wrote:
Other bare metal systems and their results with the same PEM file:
Verifies on Proxmox (the one running the VM) with openssl 1.1.1n
Verifies on Ubuntu 22.04 with opens
On 9/2/22 21:42, Shawn Heisey via openssl-users wrote:
Other bare metal systems and their results with the same PEM file:
Verifies on Proxmox (the one running the VM) with openssl 1.1.1n
Verifies on Ubuntu 22.04 with openssl 3.0.2
Fails on CentOS 7.5.1804 with openssl 1.0.2k-fips
Additional te
event this is an XY problem, here is the X: I am trying
to set up a letsencrypt certificate creation/renewal system on the VM
for work that I have running on my own server. One of the things that I
have my script doing is validating the certificate file that it produces
before it declares s
To: openssl-users@openssl.org
Problem solved. Thank you o...@integral.be and levi...@openssl.org. I
changed to Current release (stable) and called wrap.pl. This now works:
/home/bullseye/test0818/openssl/3.0.5/plain/openssl-3.0.5/util/wrap.pl
/home/bullseye/test0818/openssl/3.0.5/plain/openssl
I've implemented my own X509_STORE lookup functions.
The problem I'm having is that the store contains cert A which is being
returned when I lookup
cert B because they both have the same Common Name.
Is there a way to tell the store to look up via thumbprint rather than
Common Name
I am trying to compile fetchmail 7 (which requires Openssl 3) on my
CentOS 7 system. I installed Openssl 3 from source and it seems to be
working as expected. However, when I try to compile fetchmail 7 it fails
with these errors:
undefined reference to `OpenSSL_version'
undefined reference to
9:83:9F:A8:CE:FE:ED:52:F0:DA:93:1C:B9:F7:57:0A:BB:F3:E4:B0:EE:93:C9*
*
*
I have the same problem in debug or release .
if I do the same test with the legacy provider fips pointer is not
null and seems correct
*fips = OSSL_PROVIDER_load(NULL, "Legacy");*
is someone have an idea of w
re success*
*activate = 0 conditional-errors = 1security-checks = 1module-mac =
B9:FB:80:43:6A:58:FC:89:23:19:83:9F:A8:CE:FE:ED:52:F0:DA:93:1C:B9:F7:57:0A:BB:F3:E4:B0:EE:93:C9*
I have the same problem in debug or release .
if I do the same test with the legacy provider fips pointer is not null
and see
Well,
I used the openssl cli program, and cut everything out that wasn't required.
The results can be seen here.
https://gist.github.com/burner/4d87d1421e39627f84316bc2892e6103
Hello all,
I'm trying to follow the guide shown in
https://wiki.openssl.org/index.php/EVP_Asymmetric_Encryption_and_Decryption_of_an_Envelope
But for the life of me I can't figure out how to do the following:
```
struct Data {
unsigned char* data;
unsigned long length;
};
struct KeyArra
Hello,
I'm currently performing an upgrade from 1.0.2 to 3.0 and I'm having some
difficulties.
Our code is very old and some assumptions could have changed during time.
Anyway the problem I have right now is about d2i_ASN1_SET and i2d_ASN1_SET
functions that in OpenSSL 3 are not availab
On Thu, Jun 18, 2020 at 12:00:33PM +0200, Attila Csosz wrote:
> err = connect(sd, (struct sockaddr*) &sa, sizeof(sa));
>
> // Create SSL context
> meth = SSLv23_server_method();
Have you tried SSLv23_client_method()? Your application is a TLS
client, not a TLS server...
> if (!meth) throw
What may the problem?
My question also: I have found that maybe I have to use ERR_get_error but
this function is in an another dll (libeay32) how will this function
connect to the ssl instance?
Thanks for your help
void init_openssl()
{
SSL_load_error_strings();
SSL_library
On 22/05/2020 13:09, Claus Assmann wrote:
> On Tue, May 19, 2020, Claus Assmann wrote:
>
> Here's another (confusing) note: the (failing) S8 trace log:
>
>> Sent Record
>> Header:
>> Version = TLS 1.2 (0x303)
>> Content Type = Handshake (22)
> ...
>> extensions, length = 12
>>
On Tue, May 19, 2020, Claus Assmann wrote:
Here's another (confusing) note: the (failing) S8 trace log:
> Sent Record
> Header:
> Version = TLS 1.2 (0x303)
> Content Type = Handshake (22)
...
> extensions, length = 12
> extension_type=supported_versions(43), length=2
>
Sorry for just another (intermediate) update: further debugging
shows the I/O laywer (unsurprisingly) wasn't the problem. I have
to take some steps back and start over :-(
out is 5s or 20s).
I spent a lot of time debugging the I/O layer which is basically
stdio from Chris Torek/*BSD with timeouts. It seems there is a
problem but I'm not sure whether that's a bug in the code or it is
just not supposed to be used that way (the buffering layer discards
data whe
>Speaking of which, I've recently discovered (a documented interface
landmine) that:
status = SSL_read(ssl, ...);
err = SSL_get_error(ssl, status);
>is an anti-pattern, because the "correct" usage is:
It's not unlike checking errno without knowing if the syscall actua
issue for this?
>
> In the mean-time, if Clauss is trying to complete a handshake, rather
> than move data, his issue is then likely something different?
>
Correct - the error stack should be being cleared in this case, so the
problem is unlikely to be related to stale errors.
Matt
On Wed, May 20, 2020 at 09:40:35PM +0100, Matt Caswell wrote:
> On 20/05/2020 21:36, Viktor Dukhovni wrote:
> > My take is that this is a sufficiently nasty problem to warrant some
> > changes in SSL_read(), SSL_write, SSL_accept(), ... to internally
> > memoize the error st
On 20/05/2020 21:36, Viktor Dukhovni wrote:
> My take is that this is a sufficiently nasty problem to warrant some
> changes in SSL_read(), SSL_write, SSL_accept(), ... to internally
> memoize the error status before returning, in a manner that does not
> depend on the prior state
over on the
error stack:
http://postfix.1071664.n5.nabble.com/quot-SSL-Shutdown-shutdown-while-in-init-quot-while-sending-and-receiving-td105822.html
My take is that this is a sufficiently nasty problem to warrant some
changes in SSL_read(), SSL_write, SSL_accept(), ... to internally
memoize t
On 20/05/2020 17:52, Claus Assmann wrote:
> On Wed, May 20, 2020, Matt Caswell wrote:
>
> [Thanks for still helping me with this!]
>
>> Can you test the underlying socket to see if it has been closed down in
>> an orderly way (i.e. recv() should return 0 on the socket if so)? That
>
> Yes, th
On Wed, May 20, 2020, Matt Caswell wrote:
[Thanks for still helping me with this!]
> Can you test the underlying socket to see if it has been closed down in
> an orderly way (i.e. recv() should return 0 on the socket if so)? That
Yes, that what happens.
So I added some debugging to the client a
On 20/05/2020 14:24, Claus Assmann wrote:
> On Wed, May 20, 2020, Matt Caswell wrote:
>
>> I wonder if there could be some middlebox in between these two peers
>> that is interfering with the connection in some way and arbitrarily
>> closing it down?
>
> No, it's being tested on localhost. An
On Wed, May 20, 2020, Matt Caswell wrote:
> I wonder if there could be some middlebox in between these two peers
> that is interfering with the connection in some way and arbitrarily
> closing it down?
No, it's being tested on localhost. And it works fine if I use a
different server (e.g., opens
On 20/05/2020 13:44, Claus Assmann wrote:
> On Wed, May 20, 2020, Matt Caswell wrote:
>
>> SSL_accept:TLSv1.3 early data
>
>> What happens in the application code? What was the function being called
>> (SSL_accept?) and what return value do you get? What does
>> SSL_get_error() return at this
On Wed, May 20, 2020, Matt Caswell wrote:
> SSL_accept:TLSv1.3 early data
> What happens in the application code? What was the function being called
> (SSL_accept?) and what return value do you get? What does
> SSL_get_error() return at this point?
It's:
r = SSL_accept(srv_ssl);
output. Even if I add
> the line you suggested there's no extra output
> (to make sure there would be something I also added
> an BIO_fprintf() and that output is shown, so it's not
> a problem with the BIO).
>
> I guess I have to figure out how to use wireshark for this.
mething I also added
an BIO_fprintf() and that output is shown, so it's not
a problem with the BIO).
I guess I have to figure out how to use wireshark for this.
On 19/05/2020 11:49, Claus Assmann wrote:
> On Mon, May 18, 2020, Viktor Dukhovni wrote:
>
>> I'll strongly second Matt's request for a PCAP file.
>
> If tcpdump is "good enough" then that should be attached.
> If wireshark and some TLS decoding is needed, then I need
> some time to figure tha
On Mon, May 18, 2020, Viktor Dukhovni wrote:
> I'll strongly second Matt's request for a PCAP file.
If tcpdump is "good enough" then that should be attached.
If wireshark and some TLS decoding is needed, then I need
some time to figure that out.
> The client trace looks rather odd, why is writin
On Tue, May 19, 2020, Jan Just Keijser wrote:
> FWIW: adding TLS 1.3 support to my EAP-TLS code got me stumped for a while as
> well. I eventually added up the following snippet:
> SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_CLIENT |
> SSL_SESS_CACHE_NO_INTERNAL_STORE);
> SSL_CTX_
Hi Claus,
On 18/05/20 20:59, Claus Assmann wrote:
On Mon, May 18, 2020, Alexander Gryanko wrote:
[thanks for the hints, I will try that ASAP]
But first of all, check your cert type. Looks like you are using non-RSA
cert which is not supported by S8.
As I wrote: it works fine if I don't use T
On Mon, May 18, 2020 at 06:59:59PM +0200, Claus Assmann wrote:
> I'm stuck and looking for some hints/help. I have two MTAs (let's
> call them M1 and S8), both built with OpenSSL 1.1.1g. The problem
> is M1 cannot establish a TLSv1.3 connection with S8. Using other
> MTAs
On Mon, May 18, 2020, Alexander Gryanko wrote:
[thanks for the hints, I will try that ASAP]
> But first of all, check your cert type. Looks like you are using non-RSA
> cert which is not supported by S8.
As I wrote: it works fine if I don't use TLSv1.3 or if I use openssl
s_client with TLSv1.3 (
s (let's
> call them M1 and S8), both built with OpenSSL 1.1.1g. The problem
> is M1 cannot establish a TLSv1.3 connection with S8. Using other
> MTAs/sites/protocols/tools works just fine, e.g., M1 can send mail
> to google using TLSv1.3, and S8 can send mail to M1. Replacing th
Are you able to capture a wireshark trace of the handshake?
Matt
On 18/05/2020 17:59, Claus Assmann wrote:
> I'm stuck and looking for some hints/help. I have two MTAs (let's
> call them M1 and S8), both built with OpenSSL 1.1.1g. The problem
> is M1 cannot establish a TLSv
I'm stuck and looking for some hints/help. I have two MTAs (let's
call them M1 and S8), both built with OpenSSL 1.1.1g. The problem
is M1 cannot establish a TLSv1.3 connection with S8. Using other
MTAs/sites/protocols/tools works just fine, e.g., M1 can send mail
to google using TLSv1
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Andreas Tengicki
> Sent: Thursday, May 07, 2020 03:23
>
> 3) myserver vs openssl (and my client) is not working
Did you do what I told you to do in my previous message? That is:
> > Get rid of the call to use_certific
On a tangent, this file format (and order) was actually finally
standardized as "application/pem-certificate-chain" by RFC 8555
section 9.1 (the Automatic Certificate Management Environment
protocol, or ACME).
On Wed, May 6, 2020 at 2:59 PM Michael Wojcik
wrote:
> Get rid of the call to use_certi
ts Pty Ltd, CN =
> CLIENT001
>
> Error:
> =
>
> If the client connects the server there are the following errors:
>
> server:
> 139918902234240:error:1416F086:SSL
> routines:tls_process_server_certificate:certificate verify
> failed:../ssl/statem/statem_clnt.c:1915:
>
> client:
>
ssl-users-boun...@openssl.org] On Behalf Of
>> Andreas Tengicki
>> Sent: Wednesday, May 06, 2020 12:45
>> To: openssl-users@openssl.org
>> Subject: mutual-TLS / mTLS Example with certificate problem
>>
>> I can not find a working mutual-TLS server/client example on g
On 06/05/2020 19:44, Andreas Tengicki wrote:
> SSL_CTX_set_ecdh_auto(srvCtx->ctx, 1);
Viktor and Michael have already provided some excellent advice on this
so I won't cover the same ground. Just one note on this line though -
this is actually unnecessary in modern versions of OpenSSL (anythin
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Andreas Tengicki
> Sent: Wednesday, May 06, 2020 12:45
> To: openssl-users@openssl.org
> Subject: mutual-TLS / mTLS Example with certificate problem
>
> I can not find a working mutual-TLS ser
On Wed, May 06, 2020 at 08:44:57PM +0200, Andreas Tengicki wrote:
> SSL_CTX_load_verify_locations(srvCtx->ctx,NULL,"../certs"); //
Have you run "c_rehash" on "../certs" (not keen on relative file names
here myself).
> Client Side
> =
>
> SSL_CTX_set_ecdh_auto(ctx, 1);
>
On Wed, May 06, 2020 at 08:44:57PM +0200, Andreas Tengicki wrote:
> I can not find a working mutual-TLS server/client example on github or
> the whole internet. Only some example for pieces of code. Communication
> via socket without and with encryption (openSSL) is working, but with
> mTLS not. I
:certificate verify
failed:../ssl/statem/statem_clnt.c:1915:
client:
139918902234240:error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify
failed:../ssl/statem/statem_clnt.c:1915:
I think, there is a problem with the certificates. But where is the
problem and why?
The statem
I hope this is fixed by https://github.com/openssl/openssl/pull/11655
On Mon, 27 Apr 2020 23:14:12 +0200,
Norm Green wrote:
>
> I don't know if this change was intentional or not.
> With 3.0 alpha, compiling this simple program on Linux fails but
> succeeds on 1.1:
>
> -
> #inclu
I don't know if this change was intentional or not.
With 3.0 alpha, compiling this simple program on Linux fails but
succeeds on 1.1:
-
#include
gcc -c -I \
/home/normg/local/gs360_opensslv3/slow50/openssl/install50/include test.c
In file included from
/hom
On 24/04/2020 17:38, Claus Assmann wrote:
> It seems something went wrong when include/openssl/opensslv.h
> was generated?
>
> cc -Icrypto -I. -Iinclude -Iproviders/common/include
> -Iproviders/implementations/include -Icrypto/include -DAES_ASM -DBSAES_ASM
> -DCMLL_ASM -DECP_NISTZ256_ASM -D
It seems something went wrong when include/openssl/opensslv.h
was generated?
cc -Icrypto -I. -Iinclude -Iproviders/common/include
-Iproviders/implementations/include -Icrypto/include -DAES_ASM -DBSAES_ASM
-DCMLL_ASM -DECP_NISTZ256_ASM -DGHASH_ASM -DKECCAK1600_ASM -DMD5_ASM
-DOPENSSL_BN_ASM_GF
***
*** OpenSSL has been successfully configured ***
*** ***
*** If you encounter a problem while building, please open an***
*** issue on GitHub <https://github.com/openssl/openssl/issues
<https://
***
*** OpenSSL has been successfully configured ***
*** ***
*** If you encounter a problem while building, please open an***
*** issue on GitHub <https://github.com/openssl/openssl/issues
<https://
round, but remain puzzled. On a FreeBSD 12.1
>> system with OpenSSL 1.1.1d
> 1.1.1d != 1.1.1
Yes, if it was truly 1.1.1 without the 1.1.1a patches, then your symptoms
are expected. The message from Dan Fulger suggested that perhaps it was
1.1.1c, but maybe that's a different system than the one on which you
observed the problem.
Likely you're all set. Good luck.
--
Viktor.
On Mon, Mar 30, 2020 at 09:37:51AM +0100, Jeremy Harris wrote:
> On 30/03/2020 08:41, Dan Fulger wrote:
> > Indeed, CentOS 8.0 has OpenSSL 1.1.1 with very few updates.
> > But CentOS 8.1 was released in January, with OpenSSL 1.1.1c.
>
> Fortunately, with Viktor's help, the application fix is a
>
On 30/03/2020 08:41, Dan Fulger wrote:
> Indeed, CentOS 8.0 has OpenSSL 1.1.1 with very few updates.
> But CentOS 8.1 was released in January, with OpenSSL 1.1.1c.
Fortunately, with Viktor's help, the application fix is a
one-liner and is compatible across versions.
--
Cheers,
Jeremy
Indeed, CentOS 8.0 has OpenSSL 1.1.1 with very few updates.
But CentOS 8.1 was released in January, with OpenSSL 1.1.1c.
On Fri, Mar 27, 2020 at 10:10:16PM +, Jeremy Harris wrote:
> >> A simple code addition to avoid that call in the client case sounds
> >> in order.
>
> Testing, it appears to work - I get resumption and not that error.
> And the Exim testsuite shows no regressions, at least on my laptop
> (wh
On 27/03/2020 21:52, Viktor Dukhovni wrote:
> On Fri, Mar 27, 2020 at 09:25:28PM +, Jeremy Harris wrote:
>
>>> If the distro started with 1.1.1 and only backported security fixes, you
>>> could be running an OpenSSL version with the unintentional bidirectional
>>> setting.
>>
>> .. either this
On Fri, Mar 27, 2020 at 09:25:28PM +, Jeremy Harris wrote:
> > If the distro started with 1.1.1 and only backported security fixes, you
> > could be running an OpenSSL version with the unintentional bidirectional
> > setting.
>
> .. either this, or even an unpatched basic 1.1.1 .
>
> A simpl
On 27/03/2020 21:07, Viktor Dukhovni wrote:
> That function should only affect the server -> client direction.
> Briefly, in OpenSSL 1.1.1 it affected both the client and server
> directions, but this was fixed in OpenSSL 1.1.1a.
If Centos is following the same pattern in 8 as they did in 7,
they
On Fri, Mar 27, 2020 at 08:20:55PM +, Jeremy Harris wrote:
> > Right, you're running out of space by trying to send too many
> > CA names. It is better to have this fail, so you can figure
> > what is trying to dump your entire trusted CA list (of names)
> > to the server, than to actually ha
On 26/03/2020 00:58, Viktor Dukhovni wrote:
> On Thu, Mar 26, 2020 at 12:40:08AM +, Jeremy Harris wrote:
>
>> Looks like I'm wrong, from the behaviour.
>>
>> It's the second of the possible places, and "i" is 129.
>> It appears to be failing the WPACKET_sub_allocate_bytes_u16()
>> call. %rs
On Thu, Mar 26, 2020 at 12:40:08AM +, Jeremy Harris wrote:
> Looks like I'm wrong, from the behaviour.
>
> It's the second of the possible places, and "i" is 129.
> It appears to be failing the WPACKET_sub_allocate_bytes_u16()
> call. %rsi before the call, which I think should be
> the "na
On 24/03/2020 20:25, Viktor Dukhovni wrote:
>>> I'm guessing it is not the first. The second would an issue with a
>>> particular issuer on the CA list (does Exim configure a list of CAs to
>>> send to the server?),
>>
>> I don't think so
Looks like I'm wrong, from the behaviour.
It's the second
در تاریخ سهشنبه ۲۴ مارس ۲۰۲۰، ۵:۲۰ Viktor Dukhovni <
openssl-us...@dukhovni.org> نوشت:
> On Mon, Mar 23, 2020 at 05:27:55PM -0700, Benjamin Kaduk via openssl-users
> wrote:
>
> > > I *think* possibly also the precise nature of that client cert
> > > matters; a testcase I set up away from my prod
On Mon, Mar 23, 2020 at 05:27:55PM -0700, Benjamin Kaduk via openssl-users
wrote:
> > I *think* possibly also the precise nature of that client cert
> > matters; a testcase I set up away from my production
> > system failed to induce the error. The client cert
> > is loaded using SSL_CTX_use_cer
On Mon, Mar 23, 2020 at 11:46:43PM +, Jeremy Harris wrote:
> OpenSSL 1.1.1 on Centos 8
> Ticket-based resumption
I'm testing posttls-finger with OpenSSL 1.1.1 on FreeBSD.
>
> I'm getting a repeatable error from a client call to SSL_connect()
> of "14228044:SSL routines:construct_ca_names:i
On Mon, Mar 23, 2020 at 11:46:43PM +, Jeremy Harris wrote:
> OpenSSL 1.1.1 on Centos 8
> Ticket-based resumption
>
>
> I'm getting a repeatable error from a client call to SSL_connect()
> of "14228044:SSL routines:construct_ca_names:internal error".
>
> Packet capture shows an Alert being s
OpenSSL 1.1.1 on Centos 8
Ticket-based resumption
I'm getting a repeatable error from a client call to SSL_connect()
of "14228044:SSL routines:construct_ca_names:internal error".
Packet capture shows an Alert being sent by the client before
anything is received from the server.
The error only
On Fri, Jan 03, 2020, Benjamin Kaduk via openssl-users wrote:
> On Sun, Nov 24, 2019 at 12:05:34PM +0100, Claus Assmann wrote:
> > Seems it is impossible to override the list with NULL for SSL, as
> > the code will then use the list from CTX (if my limited understanding
> > Is this intentional? T
Sorry for the very late response...
On Sun, Nov 24, 2019 at 12:05:34PM +0100, Claus Assmann wrote:
> Seems it is impossible to override the list with NULL for SSL, as
> the code will then use the list from CTX (if my limited understanding
> of the code is correct):
>
> STACK_OF(X509_NAME) *SSL_ge
Seems it is impossible to override the list with NULL for SSL, as
the code will then use the list from CTX (if my limited understanding
of the code is correct):
STACK_OF(X509_NAME) *SSL_get_client_CA_list(const SSL *s)
{
...
if (s->client_CA != NULL)
return (s->client_CA);
I'm trying to find what's wrong when I use
SSL_set_client_CA_list(ssl, NULL);
in a server:
openssl s_client still shows "Acceptable client CA names"
(those which are previously set using
SSL_CTX_load_verify_locations())
instead of the expected
"No client certificate CA names sent"
which happens if
Hi,
I am using following openssl versions
openssl-1.0.2r.tar.gz
openssl-fips-2.0.5.tar.gz
Following are my files,
*foo.c* :
[root@data-domain-dev-vm poc]# cat foo.c
#include
#include
#include
int foo_func()
{
int rc, mode;
mode = FIPS_mode();
if(mode == 0)
{
rc = FIPS_
-Wimplicit-function-declaration]
> error("EVP_KDF_CTX_new_id");
> ^
> perror
> test.c:15:9: warning: implicit declaration of function ‘EVP_KDF_ctrl’; did you
> mean ‘EVP_KDF_size’? [-Wimplicit-function-declaration]
> if (EVP_KDF_
entifier is reported only once for
>> each function it appears in
>> test.c:13:9: warning: implicit declaration of function ‘error’; did you mean
>> ‘perror’? [-Wimplicit-function-declaration]
>> error("EVP_KDF_CTX_new_id");
>> ^
>
ion-declaration]
> error("EVP_KDF_CTX_new_id");
> ^
> perror
> test.c:15:9: warning: implicit declaration of function ‘EVP_KDF_ctrl’; did
> you mean ‘EVP_KDF_size’? [-Wimplicit-function-declaration]
> if (EVP_KDF_ctrl(kctx, EVP_KD
"EVP_KDF_CTX_new_id");
^
perror
test.c:15:9: warning: implicit declaration of function ‘EVP_KDF_ctrl’; did
you mean ‘EVP_KDF_size’? [-Wimplicit-function-declaration]
if (EVP_KDF_ctrl(kctx, EVP_KDF_CTRL_SET_MD, EVP_sha256()) <= 0) {
^~~~
Cc: Richard Levitte ; Michael Wojcik
; Matt Caswell ;
openssl-users@openssl.org
Subject: Re: Problem with the SHA256 signatures (download files) for the new
releases 1.1.1d, 1.0.2t, 1.1.0l etc
Thanks for the heads up.
For some reason, the information at our CDN remained incorrect for the &quo
---Original Message-
> From: Richard Levitte [mailto:levi...@openssl.org]
> Sent: Wednesday, September 11, 2019 2:41 PM
> To: Michael Wojcik
> Cc: Carl Tietjen ; Matt Caswell
> ;
> openssl-users@openssl.org
> Subject: Re: Problem with the SHA256 signatures (download files) for the
, 2019 2:41 PM
To: Michael Wojcik
Cc: Carl Tietjen ; Matt Caswell
; openssl-users@openssl.org
Subject: Re: Problem with the SHA256 signatures (download files) for the new
releases 1.1.1d, 1.0.2t, 1.1.0l etc
Issue found... Apache detected .gz in the file name and set the encoding to
Issue found... Apache detected .gz in the file name and set the
encoding to 'application/x-gzip'... Apparently, we already force .asc
and .sha1 files to application/binary, but have apparently not added a
similar directive for .sha256 files.
Now done.
Cheers,
Richard
On Wed, 11 Sep 2019 22:04:
I can confirm Carl's issue when I download using Pale Moon (a Firefox fork):
-
$ file openssl-1.1.1d.tar.gz.sha256
openssl-1.1.1d.tar.gz.sha256: gzip compressed data, from FAT filesystem (MS-DOS,
OS/2, NT)
$ file openssl-1.1.1d.tar.gz.sha1
openssl-1.1.1d.tar.gz.sha1: ASCII text
$ file opens
: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Matt Caswell
Sent: Wednesday, September 11, 2019 11:10 AM
To: openssl-users@openssl.org
Subject: Re: Problem with the SHA256 signatures (download files) for the new
releases 1.1.1d, 1.0.2t, 1.1.0l etc
On 11/09/2019 18:08, Carl
On 11/09/2019 18:08, Carl Tietjen wrote:
> Hello,
>
> From the download site, https://www.openssl.org/source/ click the SHA256 link
> for the new releases. The files do not contain SHA256 hashes.
>
> FYI -- The SHA1 hashes seem to be ok -- I only checked one.
These seem to be ok for me?
Mat
Hello,
>From the download site, https://www.openssl.org/source/ click the SHA256 link
>for the new releases. The files do not contain SHA256 hashes.
FYI -- The SHA1 hashes seem to be ok -- I only checked one.
Thanks,
Carl
1 - 100 of 3569 matches
Mail list logo
