Hello group,
I have a question regarding the verify method of OpenSSL: If I have a
certificate chain
Root -> A -> B -> Leaf
where "Leaf" is the certificate of a webserver (https) and Root is a
self-signed certificate.
In this scenario, is it valid for the webserver to provide only A/B/Leaf
and
On 12.01.2012 19:05, Kenneth Goldman wrote:
>> I have a question regarding the verify method of OpenSSL: If I have a
>> certificate chain
>>
>> Root -> A -> B -> Leaf
>>
>> where "Leaf" is the certificate of a webserver (https) and Root is a
>> self-signed certificate.
>>
>> In this scenario, is it
On 12.01.2012 19:23, Michael S. Zick wrote:
> On Thu January 12 2012, Johannes Bauer wrote:
>> Hello group,
>>
>> I have a question regarding the verify method of OpenSSL: If I have a
>> certificate chain
>>
>> Root -> A -> B -> Leaf
>>
>>
On 13.01.2012 01:02, Dave Thompson wrote:
>>> The verify fails. Why is that? The immediate signature is valid, does
>>> the "verify" command expect to always terminate at a self-signed
>>> certificate?
>>>
> Yes. Or rather the libcrypto routine X509_verify_cert, used by the
> 'verify' utility and
On 13.01.2012 10:15, Curt Sampson wrote:
> On 2012-01-13 09:54 +0100 (Fri), Johannes Bauer wrote:
>
>> Let's say I have some "ultimate" root A which has issued a sub-CA "B"
>> for me. I use "B" to create, for example, a certificate for my we
On 24.02.2012 03:51, burtbick wrote:
> So the new questions are:
> Is des-ede the proper choice for "Triple DES-ECB" as the target device
> specification requires? If not then is there another viable option?
You can use 3K3DES and have the same results (with lower performance) if
you set K1 = K3
Hello list,
I get CSR from people which have not necessarily set the subject values
set to the correct values. Instead of forcing them to enter exact values
(how I do it at the moment and which works TERRIBLY), I'd just like to
change them myself and use the PK they provide within the CSR. I can d
Patrick Patterson schrieb:
> Check out the archives, and see my reply to Martine Schneider and David
> Schwartz from yesterday to the query:
>
> Sign CSR after modifying data in CSR possible?
A, thanks! With "openssl ca" it's possible, but I've been using
"openssl x509 -req" so far.
Thanks
Hello list,
I'm having trouble with the openssl enc feature. This here:
echo -n '0123456789abcde' | openssl enc -aes128 -nosalt -K
00112233445566778899aabbccddeeff -iv | wc -c
(encoding 15 characters) results in one result block being generated: The
command res
Original-Nachricht
>
> padding
Why would a 16 byte block need to be padded by one byte to 17 bytes?
Regards,
Johannes
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
_
Hi list,
I have a rather simple question regarding X.509 subjects that is not
entirely clear to me and for which I cannot find the appropriate
reference (pointers greatly appreciated). The trouble starts when trying
to compare two subjects of *different* certificates for equality and
becomes worse
Hi list,
I'm quite puzzled and hope somebody can help me. I'm handling a large
number of certificates and for generating testcases for the software I
employ, I wrote a small script that downloaded web server certificates
en bulk and then processed them, to check for irregularities.
My software ba
Hi list,
I'm having trouble getting a TLS 1.2 with EC F_p certificates to run.
This is my setup:
Server: openssl 1.0.1e compiled from source, Debian squeeze
Client: openssl 1.0.1c from Gentoo tree
On the Server, i get
$ openssl ciphers -v
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA
On 15.05.2013 17:48, Johannes Bauer wrote:
> Server: openssl 1.0.1e compiled from source, Debian squeeze
> Client: openssl 1.0.1c from Gentoo tree
Additional info: Just upgraded the Client to 1.0.1e (Gentoo) and have
the same issue. Something is *seriously* wrong here. That's what
On 15.05.2013 20:52, Dave Thompson wrote:
> I can't easily test at the moment (even assuming your client is OpenSSL),
> but I speculate that in SSL3 mode the client doesn't send (Client)Hello
> extensions for SupportedCurves and SupportedPointFormats,
Correct.
> and in TLS
> mode(s?) it does.
On 15.05.2013 21:17, Johannes Bauer wrote:
> Only sect/secp are included curiously although my openssl client
> does internally also know, for example, about the wap-wsg and X9.62
> curves. But those are not included in the Client Hello request.
>
> And there's definitely
On 15.05.2013 23:05, Dr. Stephen Henson wrote:
> On Wed, May 15, 2013, Johannes Bauer wrote:
>
>>
>> Does this mean that communication with TLS1.2 with curves other than the
>> SEC-curves has actually never worked with OpenSSL (because it couldn't
>> have worked
Hi list,
I'm in the process of refactoring/updating code that has been using
TLS-PSK with TLSv1.2 for a number of years successfully. I want to
upgrade it so that it uses TLSv1.3 exclusively.
I find it *exceptionally* hard to wrap my head around the new API and
the documentation/manpages are extr
On 23.10.19 11:24, Johannes Bauer wrote:
> All error checking omitted for now, this is obviously just a sample.
> When I try to connect to my server on the command line using s_client:
>
> $ openssl s_client -connect 127.0.0.1:12345 -psk_identity foo -psk 001122
>
> The ser
Hi list,
yet another question. In my process with TLS13-PSK, I've noticed that
the PSK callback does not have a user-definable callback context value.
However, the callback is passed the SSL* which I created when the
session was established.
Is there a way for me to piggyback a void* inside the S
On 23.10.19 15:21, Salz, Rich wrote:
>>Is there a way for me to piggyback a void* inside the SSL structure so
> that I can access it from within the callback?
>
> Yes, you can use SSL_set_app_data and SSL_get_app_data which are documented
> in https://github.com/openssl/openssl/pull/10216
Hi list,
when I use OpenSSL I suspect some funny business going on with the HMAC
computation of "openssl dgst" command line tool. Consider:
$ echo -n foobar | openssl dgst -sha256 -hex -hmac aabbcc
(stdin)= 6e74cdc3b72b8b66535b914357c7d656a22acbb1700b4e6de688fd5c091d305c
But
#include
#include
On 03.02.2015 10:00, Johannes Bauer wrote:
> when I use OpenSSL I suspect some funny business going on with the HMAC
> computation of "openssl dgst" command line tool. Consider:
Damn, I'm sorry. Forgot to include the version:
OpenSSL 1.0.1f 6 Jan 20
On 03.02.2015 11:16, Billy Brumley wrote:
>> $ echo -n foobar | openssl dgst -sha256 -hex -hmac aabbcc
>> (stdin)= 6e74cdc3b72b8b66535b914357c7d656a22acbb1700b4e6de688fd5c091d305c
>
> This gets posted every once in a while -- google around. Something
> about the hmac switch not doing what you thin
24 matches
Mail list logo
