Should applications accessing a user-specified host over HTTPS attempt to provide assistance by looking up its FQDN?

Accessing applications on user-specified hosts through HTTPS is a common requirement, but some confusion may be encountered in actual applications. For this problem, PHP editor Banana thinks we should try to help by looking up the FQDN. FQDN (Fully Qualified Domain Name) is a fully qualified domain name, including the host name and domain name. By looking up the FQDN, you can ensure that the host specified by the user is accurately located, thereby providing accurate help and services. Therefore, looking up the FQDN is a beneficial strategy when making HTTPS access.

Question content

I am using a golang application that communicates with the server over HTTPS on another host. Specifically, if context matters: Communicate with a Dataproc cluster from a GCE instance in the same Google Cloud project (no special domain setup required).

The server generates a self-signed certificate, which I have manually installed on the client.

Both the server and client are GCE instances on my Google Cloud project (their FQDN is 581ce0c2a03eb2244e4d3a83f2c5e59d.c.ebfcb145e568f70e9a690c02a46a321e.internal)

If I try to connect to the server from the client using golang's http.Client, I get an error like this:

failed to verify certificate: x509: certificate is valid for *.c.<project_id>.internal, not <server_hostname>

However, if I pass it its FQDN (4c7198d8b6b4fb195532e2caff10f39a.c.ebfcb145e568f70e9a690c02a46a321e.internal), it works out of the box.

FYI, this behavior is consistent with what I see when running cURL:

curl: (60) SSL: no alternative certificate subject name matches target host name '<server_hostname>'

So my question is:

1. Why doesn't it work with short/partial hostnames? It's in the same domain, so it's part of *.c.ebfcb145e568f70e9a690c02a46a321e.internal and it works out of the box, no? Or does it always require that the string passed in be used to actually match the wildcard string (meaning it doesn't do a lookup and only works if you pass in an fqdn)?
2. What are the best practices when building applications for distribution? Should I add some logic to have it calculate the FQDN so that it can convert the short name into a long name that is more likely to be used with a self-signed certificate, or leave it up to the caller to figure out the cryptic error message? Li>

NOTE: I don't want to skip validation - I just want to better understand what's going on and know what the best practices are here.

Thanks!

Solution

1. Certificates are matched against domains/hosts based on the names contained within them, so even if 4c7198d8b6b4fb195532e2caff10f39a and 4c7198d8b6b4fb195532e2caff10f39a.c.ebfcb145e568f70e9a690c02a46a321e.internal resolve to Same content, the certificate only contains the second one (or a wildcard matching it). Since these are self-generated, you can add short names in them as SANs (Subject Alternative Names). Additional flags for OpenSSL:

-addext "subjectAltName = DNS:localhost,DNS:<server_hostname>"

It is unlikely that a public CA will provide you with a certificate with a SAN that is not publicly resolvable. (Some possibilities, I haven’t tried it)

As an example, you don't want to serve or trust google.com from google.com.someevildomain.org, so this is a security feature.

1. It depends on the situation. If you have control over the certificate, just add the name you wish to use. This may end up being a single certificate with many SANs, in which case it may be cleaner to have everyone talk using an FQDN. If you can import many certificates, it's better to have each service have its own certificate with FQDN and short name.

The above is the detailed content of Should applications accessing a user-specified host over HTTPS attempt to provide assistance by looking up its FQDN?. For more information, please follow other related articles on the PHP Chinese website!