Hostname/IP doesn't match certificate's altnames

Describe the bug I’m trying to connect to bunny-cdn FTP(https://bunnycdn.com/) using the code from the example https://github.com/patrickjuchli/basic-ftp#introduction

And I get the following error:

Error: Hostname/IP doesn't match certificate's altnames: "Host: localhost. is not in the cert's altnames: DNS:*.storage.bunnycdn.com, DNS:storage.bunnycdn.com" (data socket)

Yet the host I specified is different, I used “storage.bunnycdn.com” as the host value. Where does the “localhost” come from?

I’m able to connect to the same server using the same settings when using other FTP clients

Example code

async function example() {
    const client = new ftp.Client()
    client.ftp.verbose = true
    try {
        await client.access({
            host: "storage.bunnycdn.com",
            user: "USER",
            password: "PASS",
            secure: true
        })
        console.log(await client.list())

    }
    catch(err) {
        console.log(err)
    }
    client.close()
}

Console output

Connected to 116.202.118.194:21 (No encryption)
< 220 Service Ready.

> AUTH TLS
< 234 Enabling TLS Connection

Control socket is using: TLSv1.2
Login security: TLSv1.2
> USER ###
< 331 Username ok, need password

> PASS ###
< 230 User logged in

> TYPE I
< 200 Type set to Image

> STRU F
< 200 Command OK

> OPTS UTF8 ON
< 200 Command okay.

> OPTS MLST type;size;modify;unique;unix.mode;unix.owner;unix.group;unix.ownername;unix.groupname;
< 501 Syntax error in parameters or arguments.

> PBSZ 0
< 200 OK

> PROT P
< 200 OK

Trying to find optimal transfer strategy...
> EPSV
< 502 Command not implemented

> PASV
< 227 Entering Passive Mode (116,202,118,194,51,220)

Optimal transfer strategy found.
> MLSD /
< 502 Command not implemented

> PASV
< 227 Entering Passive Mode (116,202,118,194,79,182)

> LIST -a /
< 150 Opening Image mode data transfer for LIST

Downloading from 116.202.118.194:20406 (TLSv1.3)
Error [ERR_TLS_CERT_ALTNAME_INVALID] [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames: Host: localhost. is not in the cert's altnames: DNS:*.storage.bunnycdn.com, DNS:storage.bunnycdn.com

Which version of Node.js are you using? 15.2

[loilo]

I was seeing the same issue and it caused quite a bit of headache, but I have found another condition which can cause this issue: SNI. I’m noting this here fore possible future visitors of this issue.

Hostname/IP does not match certificate's altnames: Host: imaginary-domain.com. is not in the cert's altnames: DNS:*.hostserv.eu, DNS:hostserv.eu

The connection attempt was refused until I explicitly set the secureOptions.servername to the domain of the hoster where my domain is registered (hostserv.eu in that case, the altname reported in the error):

await client.access({
  host: 'imaginary-domain.com',
  port: 21,
  secure: true,
  secureOptions: {
    servername: 'hostserv.eu'
  }
})

Unfortunately, I’m an absolute beginner regarding networking stuff, so I could, for the love of me, not figure out how to programmatically determine the correct servername option.

But because my host is not hardcoded, I needed a workaround, so I solved the problem with what’s probably quite a hack: When the ERR_TLS_CERT_ALTNAME_INVALID error occurs, I parse the cert’s altnames from the error.reason and do another connection attempt with the servername set to the first altname (filtering out wildcard domains first, of course).

This has served me well so far, but I don’t know if this is correct in any way — or if the match between the cert’s altnames and the correct servername value is just a happy coincidence. Maybe someone with more experience can judge this.

FWIW, here’s the code I’m currently using to connect the client — please consider that as long as nobody with some experience can confirm that this is how it should work, this is probably just a “lucky punch” if it works:

async function connect(client, options) {
  try {
    return await client.access(options)
  } catch (error) {
    // Bail if not a secure connection
    if (!options.secure) {
      throw error
    }

    // Only attempt a second time if the altname error is thrown
    if (error.code === 'ERR_TLS_CERT_ALTNAME_INVALID') {
      client.close()

      // Try to use the first mentioned (non-wildcard) altname as servername
      let [servername] = error.reason.match(/(?<=DNS:)[a-z0-9.-]+/i) ?? []

      if (dnsMatch) {
        return await client.access({
          ...options,
          secureOptions: {
            ...(options.secureOptions ?? {}),
            servername,
          },
        })
      }
    }

    throw error
  }
}

[patrickjuchli]

Fixes this specific issue for bunnycdn. There is another one though connected to this server tracked here #187