You may also check out the results of the popular ssllabs.com test here:
https://www.ssllabs.com/ssltest/analyze.html?d=jnior.com&hideResults=on
Note however that in recent years they have become quite aggressive in
labeling things as "weak" when they are simply "slightly less than the
best that the latestbig-brand browsers support" with no consideration
for servers that try to provide compatibility for older clients in
addition to the latest hype.
As for the signature on the key exchange in SSL3/TLS1.0/TLS1.1/TLS 1.2
and the final signature in TLS1.3, those are the one signature that
causes the certificates to do anything meaningful, so I would expect all
but the most crappy clients to check it and make a very serious error
message "SOMEONE IS HACKING YOUR CONNECTION, PULL THE PLUG NOW!" or
something equally serious.
On 2020-06-25 19:09, Bruce Cloutier wrote:
Sorry,
By "If OpenSSL fails to validate this particular digital signature that
would be the case." I meant to question whether or not OpenSSL is in
fact doing the validation? In the case that the signature is being
ignored then clients wouldn't complain. They wouldn't notice.
Bruce
On 6/25/20 1:04 PM, Bruce Cloutier wrote:
Yeah. I doubt it is an OpenSSL issue directly as Apache might be feeding
the wrong key. Just need confirmation that there isn't a default key
configuration setting for OpenSSL that might be taking precedence for
who knows why.
I can connect successfully with the browser so I cannot rule out that my
TLS implementation is faulty. However, it validates with every other
site and it validates with the default install of this bitnami stack.
Once we reconfigure for the new key and certificate, this signature in
the server_key_exchange message fails. Nothing else seems to complain.
My code does, well, because I know that I actually do verify that
signature against the supplied certificate.
So to everyone else it appears that we have configured the new
certificates properly (manually achieved Let's Encrypt cert). If OpenSSL
fails to validate this particular digital signature that would be the
case. If in my TLS implementation I skip this check (actually now I just
post a warning) everything negotiates and proceeds just fine.
Obviously, THAT signature is there for a reason. I should expect if to
validate. Just don't know what key it is using?
I am not sure how to get to the Apache people or, might be, the Bitnami
folks?
Bruce
On 6/25/20 12:07 PM, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf Of
Bruce Cloutier
Sent: Thursday, June 25, 2020 10:11
Has anyone thought about this question?
From your description, it sounds like an Apache issue, not an OpenSSL one. I don't know enough about Apache configuration to comment. (I've configured a few Apache instances in my day, but never had any real issues with it, so I've never done more than search the docs for what I needed and implemented it.)
The site is https://jnior.com if
anyone wants to hit it. For me the digital signature in the
server_key_exchange does not verify.
I just tried openssl s_client, and it didn't complain about anything. Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified the chain.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
