I'm curious how exactly an SSL client verifies an SSL server's certificate
which is signed by a CA. So, during the SSL handshake, when the server sends
its certificate, will the SSL client first checks the `Issuer`'s `CN` field
from the x509 SSL certificate that it received for example, and
Yes, off-topic, sorry.
Tomas Mraz wrote in
<11264f92f87def629df40cf0b7f7b0cc8f43fbe4.ca...@openssl.org>:
|On Thu, 2021-06-17 at 17:12 +0200, Steffen Nurpmeso wrote:
|>
|> P.P.S.: Tomáš Mráz: aren't you part of PAM project too? Off-topic
|> here, but i had written a somewhat primitive yet i
On 17/06/2021 18:35, Ethan Rahn wrote:
Hello Matt,
Love the blog post, and of course a hearty thanks to everyone who worked
on the project to get it to this point.
Is the plan still to continue with the FIPS 140-2 validation instead of
140-3? Apologies for the lack of a first party source
Hello Matt,
Love the blog post, and of course a hearty thanks to everyone who worked on
the project to get it to this point.
Is the plan still to continue with the FIPS 140-2 validation instead of
140-3? Apologies for the lack of a first party source but
I'm taking a first pass at getting asynchronous certificate validation and
asynchronous stateful session-resumption working in our application.
In callbacks, when we need to perform an asynchronous action, we setup
our own internal state (bound to the SSL *) to detail what action is going
to be
On Thu, 2021-06-17 at 17:12 +0200, Steffen Nurpmeso wrote:
>
> P.P.S.: Tomáš Mráz: aren't you part of PAM project too? Off-topic
> here, but i had written a somewhat primitive yet i think nicely
> working
Yes. I am.
> pam_xdg.so is a PAM module that manages creation of the
>
Matt Caswell wrote in
<33db69e0-0f9b-c559-43f7-e5a2f85a4...@openssl.org>:
|On 17/06/2021 15:43, Steffen Nurpmeso wrote:
|> Fyi, i have $PERL5OPT=-C permanently in my environment, in
|> conjunction with LC_ALL=en_US.utf8 this results in the build error
|> as below. Prefixing LC_ALL=C fixes
On 17/06/2021 15:43, Steffen Nurpmeso wrote:
Fyi, i have $PERL5OPT=-C permanently in my environment, in
conjunction with LC_ALL=en_US.utf8 this results in the build error
as below. Prefixing LC_ALL=C fixes this.
Thanks. I submitted this as an issue on github here:
Hello.
Matt Caswell wrote in
<20210617133633.ga24...@openssl.org>:
...
| OpenSSL version 3.0 beta 1 released
...
Congratulations after a lot of work!
Fyi, i have $PERL5OPT=-C permanently in my environment, in
conjunction with LC_ALL=en_US.utf8 this results in the build error
as below.
On 2021-06-17 15:49, Viktor Dukhovni wrote:
On Sat, Jun 12, 2021 at 10:20:22PM +0200, Gaardiolor wrote:
When I compare those, they are exactly the same. But that's the thing, I
think server.sig.decrypted should be prepended with a sha256 designator
30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01
On Sat, Jun 12, 2021 at 10:20:22PM +0200, Gaardiolor wrote:
> When I compare those, they are exactly the same. But that's the thing, I
> think server.sig.decrypted should be prepended with a sha256 designator
> 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20, which is
> missing. I do
For anyone interested I've written a blog post to accompany the 3.0 beta
1 release. You can read it here:
https://www.openssl.org/blog/blog/2021/06/17/OpenSSL3.0ReleaseCandidate/
Matt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OpenSSL version 3.0 beta 1 released
===
OpenSSL - The Open Source toolkit for SSL/TLS
https://www.openssl.org/
OpenSSL 3.0 is currently in beta.
OpenSSL 3.0 beta 1 has now been made available.
Hi,
On 12/06/21 22:20, Gaardiolor wrote:
Hello,
My openssl-1.0.2k-21.0.1.el7_9.x86_64 verify fails with HSM-signed
certificates. The HSM is causing other issues and is likely
misbehaving, I think this is a HSM bug. I'm sure I'm using the correct
server.crt and rootca.crt.
$ openssl verify
14 matches
Mail list logo
