Reindl Harald wrote:
> don't matter - instead of writing a mail that should have been just fixed

I'm pretty sure the author was "filing a bug report" and not in a
position to fix it...

I'd hope that user MLs would not be particularly hostile to users
reporting things that need to be fixed...

> it's not rocket science to deploy SSL certs which match the used hostnames,
> at least not when it takes a few seconds to pase a vhost config and verify
> if all the names are listed in the cert while the main question is why a
> vhost needs that much names at all instead "THAT is the name of the
> subdomain and THAT is the certificate for it"

Eh. Getting this stuff right isn't necessarily rocket science, but it
often isn't as easy as one might expect.
Split horizon dns servers come to mind. I haven't looked at forwarding
proxies yet, but, ...

Certainly, if a server is configured to only offer a single service
(not unreasonable), it isn't enough for it to know its own hostname,
it also needs to know all legitimate dns records that might point to

(And the person maintaining a server/service isn't necessarily the
person who maintains DNS.)

Actually having a script to validate this seems useful.

FWIW, to make this email more useful, it'd be nice if:
1. worked (there's currently no server
listening on :443, so when someone goes to fix bugzilla's server, if
they could consider issuing a blog cert and enabling it for blog,
that'd be nice).
Also, unlike blog:
2. seems to have half of a server on :443, it's
listening, but not answering. It'd be nice if someone fixed it to

Assuming one has a friendly ns server (i.e. what I'm going to be stuck
doing sometime soon), one basically wants to query the name server
using dig ANY server and then run curl -sS https://{hostname} >
clamav-users mailing list

Help us build a comprehensive ClamAV guide:

Reply via email to