On 10/23 09:13, Theo Buehler wrote: > On Thu, Oct 22, 2020 at 08:44:29PM -0700, Jeremy Evans wrote: > > I was trying to diagnose a certificate validation failure in Ruby's > > openssl extension tests with LibreSSL 3.2.2, and it was made more > > difficult because the verification error type was dropped, resulting > > in a SSL_R_CERTIFICATE_VERIFY_FAILED error where > > SSL_get_verify_result returned X509_V_OK. > > Could you perhaps isolate a test case or explain the reproducer in a bit > more detail? I tried running ruby 2.7's regress from ports but that > always resulted in a SIGABRT (usually while running test_ftp.rb with or > without your diff).
Theo, Sorry about the lack of detail. This particular issue I found while trying to get the tests in the truby/openssl repository to pass with LibreSSL 3.2.2. In particular, this test: https://github.com/ruby/openssl/blob/8c6cd23f2a83db1e9f310c8158add459a18b55ad/test/openssl/test_ssl.rb#L918 What tests for hostname verification with wildcards in subjectAltName. The test uses a subjectAltName with: DNS:a.example.com,DNS:*.b.example.com,DNS:c*.example.com,DNS:d.*.example.com Apparently with LibreSSL 3.2.2, using either c*.example.com or d.*.example.com in the subjectAltName causes all hostnames to be invalid, even those that should be valid such as a.example.com and foo.b.example.com. RFC 6125 Section 6.4.3 discusses this issue. Definitely d.*.example.com is invalid and should not be used (6.4.3.1). For c*.example.com, it's up to the client whether to support that (6.4.3.3). My expectation is that subjectAltNames with wildcards that LibreSSL does not support would be ignored as it they were not present. LibreSSL's actual behavior in this case is to fail verification for all hostnames. I don't have strong feelings about how to treat this particular case. I only posted a patch because debugging the issue was more difficult due to the incorrect error code returned (X509_V_OK). > With my diff below I once got past this abort and saw this: > > OpenSSL::TestSSL#test_verify_result > [/usr/ports/pobj/ruby-2.7.2/ruby-2.7.2/test/openssl/utils.rb:279]: > exceptions on 1 threads: > <19> expected but was > <20>. > > Did you see <0> here instead? That was probably another issue. There were a lot of changes I needed to make to the ruby/openssl tests to get them to pass with LibreSSL 3.2.2. See https://github.com/ruby/openssl/pull/404 for the full pull request I have to make the tests pass. I'd love to work with a LibreSSL developer to go through the ruby/openssl tests where behavior is different for LibreSSL and determine if the differences are expected or not. Hopefully at a future hackathon. > > I think this patch will fix it. Compile tested only. OKs, or is there > > a better way to fix it? > > This will probably also address the issue with the haproxy test reported > on the libressl list: > > https://marc.info/?l=libressl&m=160339671313132&w=2 > https://github.com/haproxy/haproxy/issues/916 > > Regarding your diff, I think setting the error on the store context > should not be the responsibility of x509_verify()'s caller. After all, > x509_verify() will likely end up being public API. > > The below diff should have the same effect as yours. >From my reading of x509_verify_ctx_new_from_xsc, that appears correct and is certainly a better way to fix the issue than my patch. Thanks, Jeremy
