Add SSL configuration support

[zackbloom]

Particularly now that Amazon supports ACM certificates, it would be nice if the created Cloudfront distributions automatically selected the most appropriate SSL cert.

[renandincer]

ACM does not support wildcard certificates. (it used to not support it when I got mine!)

Do we handle selection of the matching wildcard TLS cert only? Should probably also create a (wildcard?) cert if one doesn't exist. The pain point about that is that it needs email verification from domain owner.

[renandincer]

thinking of a --use-cert flag. The outcomes from this will be either (1) there is the wildcard cert we're looking for or (2) the wildcard cert for the current domain doesn't exist and we give an error.

for every domain, there is only one possible wildcard cert possible.

[zackbloom]

I think there are two options, we either fail immediately, and require a flag (--create-cert and --use-cert perhaps), or we make the create command more interactive by default, where it will prompt the user for what to do. (but we still need to support it running headless).

[renandincer]

Here's how it would work: --create-cert = false (default) would look for certificates, if there is an appropriate one uses it --create-cert = true would look for certificates, if there is an appropriate one, uses it. if there is no new one, it would request a new cert and quit.

[zackbloom]

That's probably the wrong name then, given setting create-cert to true doesn't actually create the cert. Maybe true, false and auto are the three values to support, where true always creates a new cert.

[renandincer]

or maybe call it --request-certificate? Does exactly what it says it does. And if they run it again without it, it will find the previously asked for (and presumably approved) certificate anyways.

[zackbloom]

So saying true to that would request a cert (even if one exists), and false would not request one (but would implicitly use one which was already available)?

[renandincer]

I see where this is getting complicated. true (aka just supplying the flag) would request a cert unless the one we're about the request already exists. false would not request it but uses the cert if it already exists. Maybe this implicit action can be made clear by printing it out?

[zackbloom]

I feel like the option should just be clearer. The states you have to describe are:

• Don't setup SSL at all
• Only set it up if the cert is already there
• Set it up for me automatically (using the best cert)
• Create a cert no matter what [maybe]
• Use this specific cert [maybe]

[renandincer]

This is how I imagine a person using this feature: stout create --cert create --key XXX --secret -XXX -bucket XXX (they check their email and confirm) stout create --cert existing --key XXX --secret -XXX -bucket XXX.

There are two spots where can make implicit decisions (below): if there is a cert and they don't specify anything and if there is a cert and they say that they want to create a new one.

We can also just print out an error saying that they should use the existing cert available. However, doing this will prevent people from setting up SSL if there is an existing cert (why would one want this?)

	Cert exists	Cert doesn't exist
existing	use first valid	print error and quit
new	?	request cert and quit (wait for email)
[valid cert id]	use that cert if exists	print error and quit
[nothing]	use	don't set up a cert

[zackbloom]

I think in the [nothing] case (meaning not specifying the option) you should at least use a cert if it's available. That seems more likely what I want than the special case of intentionally not supporting SSL.

Overloading an option which should be a cert id with these magic words new & existing is a little sketchy. Also, I feel like there should be an option for the most basic case: I want to get this setup. If that requires going to my email, that's fine, just tell me what to do. I think that describes most people running stout create, but I take your point that it's ok for them to have to rerun the command with create enabled.

Do you not like the idea of having an interactive mode where we ask the user what to do (along with a rigorous way of specifying it in advance)?

[renandincer]

	Cert exists	Cert doesn't exist	Cert not approved yet
--no-ssl and --create-ssl	error	error	error
--no-ssl	don't set up a cert	don't set up a cert	don't set up a cert
--create-ssl	use existing only if originally created by Stout, otherwise create new cert	request cert and quit (wait for email)	point out the email
[nothing]	use existing match in the following order: (1) created by stout (2) exact match (3) SAN (4) wildcard	conversation (don't set up a cert if headless)	point out the email

[balupton]

I'm using cloudflare infront of the stout deployment. As stout is also a cloudflare project, it would make sense if there was automatic generation of a Cloudflare Origin Certificate for automatic configuration with the stout deployment.