I agree that I am not being explicit regarding my terminology. I don't mean to confuse. I just cannot get anywhere on this in a vacuum. So, I need to reach out. Specifically, the Signature covering the EC Diffe-Hellman Server Params in the server_key_exchange message that I eventually receive in making an outgoing client connection from my TLS implementation, does not decrypt into a valid PKCS1 ASN.1 structure (or anything recognizable). That is happening with this one server installation using Apache in a Bitnami stack (Windows machine). My TLS code is running as part of the operating system on our separate single board computer controller (JNIOR). I use the public key extracted from the supplied certificate to decrypt and then compare the calculated hash. This procedure has been successful (and signatures verify/validate/match) in every other connection attempt to other servers (including google.com). It also works with this Apache server before we move away from the default key and certificate files. Basically, our server is using some other key for this. Maybe still the default. After we point configuration to a new certificate and key. Yeah, I had at first thought that there was an intrusion. But in testing with a clean sandboxed server we see the same results. Yes, it is most likely an Apache configuration issue but, we've dug through all of that and nothing jumps out. So either we haven't configured every possible corner of this Apache server correctly, or there is some odd extension to TLS that I've missed. But as you all know, debugging in this area is difficult. jnior.com is obviously public and we need to know if we have it improperly configured. But, I need to know why in this one instance my TLS implementation fails. In either case, it is an symptom that shouldn't be ignored as you would agree. The good news is that if there were an OpenSSL bug somewhat associated with this, you all would have already mentioned it (I assume). Bruce On 6/25/20 1:32 PM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf Of >> Bruce Cloutier >> Sent: Thursday, June 25, 2020 12:10 >> >> 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. > s_client should be verifying the signature.[1] That is, it should be verifying every signature that's part of the actual TLS protocol. I admit it's not entirely clear to me which signature isn't being verified successfully by your client. > > > [1] I'm not sure "validate" is the proper term here, technically speaking. In my experience, the literature usually uses "verify" for confirming a signature. "Validate" is generally used for more complex protocols, such as certificate validation, which involves a large number of steps with various types of checks. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -- Sent using Thunderbird on Ubuntu 16.04LTS
Attachment:
signature.asc
Description: OpenPGP digital signature
