core logic outline for all-encompassing ssl/tls layer

ssl_core_logic.py

# Generic core logic outline for all-encompassing ssl/tls layer 

# user specified crt/key should get highest priority
# if you set 'key' and 'crt', they will be used above all else
if config('crt') and config('key'):
    write_out_user_cert_key()

# config('use-le') will default to False, so if
# the user wants it, they can set this to get it
# alongside not specifying a key/crt
elif config('use-le'):
    get_cert_key_from_le()

# if the user hasn't specified crt/key, or 'use-le'
# block until you get a relation from an internal CA
else:
    get_internal_cert_key_from_easyrsa_or_block()

Hi @jamesbeedy

I was thinking along the lines of:

@when('certificates-relation-joined')
def set_data(tls):
    ```Find the common things that we need to send to both easyrsa and lets-encrypt```
    tls.set_ip(public-address)
    tls.set_sans(extra-sans)
    # Set anything else that is needed to generate the tls for this charm.

@when('certificates-relation-changed')
def get_tls(tls):
    ```Find the common things that are returned from a certificates relation provider.```
    cert = tls.get_certificate()
    key = tls.get_key()
    # Do application specific things with the key and certificate.

And both easyrsa and lets encrypt implement the certiciates relation and implement it in what ever way makes sense. We need to find the common denominators of what is returned and what input is required.

If we can get lets encrypt, cfssl, and easyrsa to agree on a relation/interface then we can plug and play the different tls charm into anything that implements that one relation. I am not married to the way easyrsa uses the interface and willing to change to accommodate the other types.