`mlton.org` SSL certificate uses the wrong SAN

[Skyb0rg007]

It looks like the mlton.org website is renewing certificates via Let's Encrypt, but doing so with sf.net as the domain name. This prevents browsers from connecting to https://mlton.org.

$ openssl s_client -showcerts -servername mlton.org -connect mlton.org:443 </dev/null 2>/dev/null | openssl x509 -inform pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:c7:7f:3c:30:f9:7c:95:04:e6:96:94:57:a5:92:26:88:ed
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = E6
        Validity
            Not Before: Jan  1 02:54:59 2025 GMT
            Not After : Apr  1 02:54:58 2025 GMT
        Subject: CN = sf.net
        Subject Public Key Info:
          <Omitted>
        X509v3 extensions:
          <Omitted>
    Signature Algorithm: ecdsa-with-SHA384
    Signature Value:
        <Omitted>

The "Subject: CN = sf.net" should be "Subject: CN = mlton.org".

[MatthewFluet]

I'm not sure. For quite some time, the SourceForge documentation said that custom VHOSTs didn't work by default with their "new" https-enabled sourceforge.io hosts. They did go the extra mile for some high-visibility projects, but MLton didn't qualify: https://sourceforge.net/p/forge/site-support/24738/. And there is still this open ticket: https://sourceforge.net/p/forge/feature-requests/700/. I don't think that MLton (the project) is generating the certificates; I think that it is SourceForge.

[YawarRaza7349]

OP is referring to the following error messages Chrome gives:

A quick Google search says you need to set the "Subject Alternative Name" to fix this, but I don't know anything about this stuff. My impression from the search results was that the CN field would then not be checked for this screen, so you can probably keep it sf.net if that's the correct value for it.

[Skyb0rg007]

MLton isn't renewing the certificate itself (sf.net is SourceForge). The site seems to be hosted on sourceforge but proxied from mlton.org without terminating + reestablishing the TLS connection.

If this is the case there's documentation for fixing this here

[MatthewFluet]

I think the VHOST is setup correctly (else www.mlton.org wouldn't work at all?).

[fweimer]

The issue here is that Sourceforge is unable to use the Server Name Indicator (SNI) to select the appropriate server certificate, based on what the client/browser requests. I assume that Sourceforge simply does not implement HTTPS for project websites using custom domains because that would have been costly before the advent of Let's Encrypt and similar services. Introducing HTTPS for Project Websites suggests to use https://mlton.sourceforge.io/ instead, and that works as expected.

[Skyb0rg007]

You may need to set a CNAME record instead of an A record for the mlton.org DNS, so clients know to accept certificates from SourceForge. Removing the A record and setting CNAME=mlton.sourceforge.io would probably fix the issue, but I’m not entirely sure.

[fweimer]

It's not possible to set a CNAME at the zone apex (for mlton.org). And the presence of a CNAME does not alter name in web browsers. There is a historic Kerberos configuration which does this (and it's insecure), but I don't recall the web PKI/HTTPS doing this within the last 25 or so years.

[Skyb0rg007]

You're right, it does seem like this is a SourceForge issue then: there's at least one open issue mentioning this. The GitHub pages docs use CNAME/ANAME records to request Let's Encrypt certs for a custom domain, but this isn't implemented in SourceForce.

Unless you setup a server that redirects mlton.org to mlton.sourceforge.io this may just be unsolvable without switching hosting platforms.