Create Backend with ssl but not verify certificate

I want to create a Backend through Fastly-cli.
I want to use SSL with port 443 but not verify the certificate.
how can I disable ssl-check-cert since the default is true?

Hi @tchelet

Thanks for reaching out!

I think we’ll need a new CLI release to address this issue.

The CLI doesn’t set the API’s ssl_check_cert field unless the CLI flag --ssl-check-cert has been set (code). But (as you’ve already noted) I do see now that the API itself will default to true if ssl_check_cert has no value (docs).

We can’t change the --ssl-check-cert flag without breaking the interface (i.e. forcing a new major version release for the CLI) and so we’ll have to add a new flag to allow disabling that API field.

The standard design pattern when building CLIs is to prefix the original flag name with --no (e.g. --no-ssl-check-cert) but I’m not really a huge fan of that and would prefer to keep the flags listed together, e.g.

  • --ssl-check-cert
  • --ssl-check-cert-disable

But I am also a stickler for conventions :slight_smile: so I’ll discuss the design aspect of this change internally to see how people feel about the naming.

Ultimately I think we’ll need an extra flag to solve this problem.

I’m going to discuss this further internally and I’ll report back here when I have appropriate feedback.

Thanks again for raising this issue.


OK, so I’ve discussed this internally and we’re going to take the classical approach (i.e. implement a --no-ssl-check-cert flag). Additionally, a colleague also made a good point, which was the current --ssl-check-cert flag is redundant because it doesn’t do anything; as the API effectively does it by default.

So what we’ll do is add the --no-ssl-check-cert flag and then if someone uses --ssl-check-cert we’ll show a DEPRECATION warning, and then remove the --ssl-check-cert flag on the next major CLI release (this is because it’s unlikely we’d ever break the API by changing the default behaviour from true to false).