On Sun, 2020-11-01 at 11:16 -0500, Paul Smith wrote:
> Does anyone have any ideas about what I might check to figure out
> what's happening here? The release notes discuss enabling
> MinProtocol and MaxProtocol; I do not use these and in fact I don't
> invoke SSL_CONF_*
I have a server linked (statically) with OpenSSL 1.1.1g (GNU/Linux,
64bit). I built everything myself, I'm not using any system libraries.
I have a test in my test suite that constructs an expired self-signed
cert and attempts to use it to connect to the server. When I link my
server with OpenSS
On Tue, 2019-11-26 at 23:47 +, Jordan Brown wrote:
> Here's a paper on the subject:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
I love the fact that the "correct and safe" example they give in
"Unnecessary Uses" is neither correct nor safe (it has a potential DOS due
to memor
On Mon, 2019-06-10 at 15:14 -0400, Viktor Dukhovni wrote:
> As a safety measure, OpenSSL does not support "*.tld" wildcards.
> The non-wildcard portion of the domain name needs to have at
> least two labels. It seems I've neglected to document this... :-(
>
> You can have "*.domain.example", but
On Mon, 2019-06-10 at 20:12 +, Michael Wojcik wrote:
> > What I cut out was only the base64-encoded certificate.
>
> Yes. That was what we needed to see. The certificate.
Yep, that's my bad. Thanks for the reminder.
> As it turns out, you're hitting the OpenSSL restriction on wildcards
> wi
On Mon, 2019-06-10 at 14:23 -0400, Viktor Dukhovni wrote:
> > $ openssl s_client -connect admin0.domain:8004 \
> > -CAfile ca.cert -verify_hostname admin0.domain
> >
> > ---
> > Verify return code: 62 (Hostname mismatch)
>
> It seems that you've elided too much information. Is the host
I'm having problems trying to get wildcard matching working with
OpenSSL. Full hostname matching is working fine, but when my
certification uses a wildcard I always get an error. That includes
both with OpenSSL 1.1.1b linked into my normal client, AND with the
openssl CLI with a system default ve
Does anyone have a straightforward example of the canonical way to
handle SSL_shutdown() in OpenSSL 1.1.1? I mean both when my code is
the initiator of the shutdown and also when I'm the peer, and also for
both blocking and non-blocking BIOs?
I've read and re-read the SSL_shutdown() man page and
On Tue, 2019-03-05 at 11:28 -0800, Wim Lewis wrote:
> On 5. mar. 2019, at 10:14 f.h., Paul Smith
> wrote:
> > E.g., I'm adding my certificate with SSL_CTX_use_certificate(); is
> > there a way to get it back out?
>
> Does SSL_CTX_get0_certificate() do what you need
I'm trying to write a simple function to dump the expiration date of
the certificates in my SSL_CTX cert store.
I've managed to retrieve and show the CA certificates from the
certificate store, and the certificate chain, but I can't find a method
that retrieves the certificate itself from SSL_CTX.
On Fri, 2019-03-01 at 23:58 +0100, Richard Levitte wrote:
> The problem isn't a lack of test_docs, the issue lies in how we
> organised the manuals before (in an apps, a crypto and a ssl
> directory), and the script that builds up these pages haven't been
> updated to prefix properly per actual man
Hi all.
I'm reading with interest the details coming out with respect to the
next release of OpenSSL.
I'm curious if there's any consideration being given to updating the
API for existing interfaces, and/or checking the APIs of any new
interfaces for issues that are seen in the current API.
I'm
Not sure if anyone is aware or not, but many of the man pages on the
openssl.org site contain broken links. Basically anywhere a man page
refers to a man page in a different section, the link is broken because
it uses the same section.
So for example:
https://www.openssl.org/docs/man1.1.1/man7
Hi all.
We have a service that currently implements a home-grown secure
connection model based on SRP using AES as the cipher. We want to add
support for TLS 1.2/1.3 as well, but we have to maintain backward-
compatibility. Our app is in C++ and using OpenSSL 1.1.1.
We really don't want to crea
I filed https://github.com/openssl/openssl/issues/7941 about this FYI.
Cheers!
On Wed, 2018-12-19 at 01:56 -0500, Paul Smith wrote:
> As I understand it, it's legal to provide the exact same input and
> output buffer to EVP_EncryptUpdate and EVP_DecryptUpdate, but it's not
&g
On Wed, 2018-12-19 at 08:57 +0300, Dmitry Belyavsky wrote:
> > I would have thought that the true maximum would be round-up(inl,
> > cipher_block_size); that is, for inl values 1-15 you'd get 16
> > bytes, and for inl values 16-31 you'd get 32 bytes, etc. (I'm not
> > actually sure whether inl of 1
As I understand it, it's legal to provide the exact same input and
output buffer to EVP_EncryptUpdate and EVP_DecryptUpdate, but it's not
legal to provide pointers into different parts of the same buffer.
That's a good check.
However, my implementation is getting triggered by this code in
EVP_Dec
Hi all; I'm working with OpenSSL 1.1.1a, using the EVP interface to
encrypt/decrypt with various ciphers/modes.
I had a couple of questions:
First, the encrypt update docs say:
> the amount of data written may be anything from zero bytes to
> (inl + cipher_block_size - 1)
Is that really true?
18 matches
Mail list logo
