Fix error in capturing key/cert file path - connects to #367

[larryschirmer]

When opening an https connection I noticed that express-gateway/lib/gateway/server.js is having issues properly capturing the file path in the .yml.

The for in loop is trying to pull properties from httpsConfig.tls when the object is defined as an array

//httpsConfig
{
    "port": 9443,
    "tls": [
        {
            "localhost": {
                "key": "localhost.key.pem",
                "cert": "localhost.cert.pem"
            }
        },
        {
            "default": {
                "key": "localhost.key.pem",
                "cert": "localhost.cert.pem"
            }
        }
    ]
}

The issue was resolved by looping through the tls array and assigning each domain object to certPaths.

[kevinswiber]

Can this be collapsed to something like:

const domainNames = httpsConfig.tls
  .map(Object.getOwnPropertyNames)
  .reduce((a, b) => a.concat(b));

It's throwing here when missing tls config.

@DrMegavolt I think you worked on this in the past. What behavior should we expect if no tls configuration exists? Should we log a warning? Exit with a config validation error? Thoughts?

[larryschirmer]

@kevinswiber great code condensing suggestion.

CircleCI is showing quite a few errors and warnings with my pull request. Is this all caused by a disruption from this change?

Also, if no tls option is set in gateway.config.yml for https i.e.

https:
  port: 9443

then npm start silently fails to begin listening on the specified port allowing the process to continue with no error output.

Should an error be thrown in this file to make a developer aware of the potential bug?

[DrMegavolt]

@kevinswiber @larryschirmer

this fails in Circle CI if not tls provided in https section. so additional check is needed (+test update to rm https section if it is not in use).

there is a variant TLS-PSK that does not need a certificate. And it seems to be not supported by node.js nodejs/node#6701

So until then certificates are required. And I would imaging throwing an error and preventing start would be a good option.

[larryschirmer]

@DrMegavolt @kevinswiber
I would like to close this pull request, and replace it with a different pull request that addresses an easier error in the documentation. See latest comment in issue 367. Is there additional work that should be preserved from this pr before I close it?

[kevinswiber]

@larryschirmer We can close this. No worries. Thanks for taking another stab at it!