Re: gnuplot.info unreachable (DNS failure)

[Mojca M. G. <moj...@gm...>]

On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...> wrote:

>
>
> On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter <pet...@gm...>
> wrote:
>
>> The error message means that the certificate required to serve the site
>> over HTTPS is not valid for the domain name gnuplot.info (nor
>> www.gnuplot.info
>> <https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$>).
>> If you look at the certificate (offered by Firefox next to the error
>> message), you can see that it was issued by Let's Encrypt to
>> secureprojects.sourceforge.net, and it is valid for a large selection of
>> other domain names, presumably all projects hosted by SF.
>>
>
> Thank you for your insights.
>
> I think you are addressing a different issue - whether the connection
> protocol is https or http.
>

Yes, this is not about DNS failure. I don't experience DNS failure, but see
precisely the same errors/issues as Peter described.

(Nowadays http should actually redirect to https. Modern browsers also
refuse to show http pages.)

It is not surprising that a certificate issued to SourceForge would not
> mention gnuplot.info by name because that name is not connected to
> SourceForge except in that (as I understand it) it currently redirects
> queries to the actual gnuplot site gnuplot.sourceforge.net.
>

Except that it does matter for https. The hosting site needs to know that
the certificate should also be for gnuplot.info  and it needs to be
explicit whether that is with or without www (or both).
Either a separate certificate is needed for that, or the certificate used
needs to be made aware that it needs to cover gnuplot.info. This really
needs to be fixed on the hosting site, and usually the person in charge of
the DNS is also needed in the process of making it work.

Unless the administrators of gnuplot on SF have access to certificate
settings (means you would also need to create and extend your own
certificate), then SF support is really needed here to set it up.

The current problem seems to be that the redirection itself fails in some
> cases, or fails to pass through sufficient information
>

No. It's really a misconfigured site/certificate.

> You still see the site, correct?

Well ... yes and no, but the more correct answer is probably NO. By default
you don't see the site because the web browser is protecting you from "the
malicious site" until you approve an exception and security risk, but that
is "an advanced use" (it is on purpose made difficult to do that).

For completeness I should mention that the issue of connection via IPv6 as
> opposed to IPv4 was raised earlier, and might be relevant,
>

It is possible that the site works correctly on IPv4 and fails with IPv6.
My network right now doesn't support IPv6, so it's hard for me to check. It
is unrelated to certificate issues, but it could hypothetically explain why
DNS works for others and not for you if you have IPv6. (By correctly I mean
resolving to the correct website. It still doesn't serve a compliant
certificate.)

Mojca

>