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!
Summary:
I think we’ll need a new CLI release to address this issue.
Details:
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 
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.
UPDATE:
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).
UPDATE 2: