On 18.11.2018 17:19, Andrea Pescetti wrote: > Pedro Lino wrote: >> However the AOO site does not specify any charset. Could that be the >> problem? > > I don't think the charset is a major issue, but indeed (if I do the > same test with openssl) there is something interesting that can > probably be submitted to Infra for investigation. > > On any system I've tried with (CentOS, Ubuntu, Fedora) > > $ openssl s_client -state -nbio -connect ooo-updates.apache.org:443 > > will show (in a lengthy output that I don't have the time to debug > now) that it is using this certificate: > > 0 s:/OU=Domain Control Validated/OU=EssentialSSL > Wildcard/CN=*.openoffice.org > > Note that I requested apache.org and I get a certificate valid for > *.openoffice.org.
The subject alternative names (which are the real identities that should match, not the common name) are '*.openoffice.org' and 'openoffice.org'. And you're right ... the certificate is wrong ... but making the same request with cURL will give the right certificate. Most likely that's because s_client doesn't send the Server Name Indication that would let HTTPd select the correct virtual host, so it'll select the "first" one. > The same holds if I use just apache.org or openoffice.org And this tends to prove the above assumption. > This mismatch itself doesn't explain much since the connection still > works, but it probably gives a hint for asking Infra why this happens. > > The output I get is very different depending on the system I use (I > get dozens of errors on some systems, a cleaner output in Ubuntu) but > in all cases openssl manages to connect in the end. I think it's best to gather all the info in this thread and create an Infra ticket. -- Brane
