Added support for self-signed SSL certificates #234
Conversation
* Added a new flag "enable-insecure" to specify whether or not the proxy should allow insecure SSL connections/requests. * Implemented that functionality for the generic provider which applies in turn to all of them.
|
Branch rebased and ready for merging. |
|
@omazhary can you describe your motivations for Self-signed cert capability? |
|
It's only for development environments where no one uses CA signed certs. However, once it goes productive, SSL (strict) gets re-enabled. |
|
@omazhary so you are trying to set |
|
@jehiah nope, all requests should be insecure. If the upstream resource has a self-signed cert, it doesn't work. The same happens with the authentication provider. For instance, we're testing this with grafana as an upstream resource, and using cloudfoundry's UAA as an authentication provider (hence PR #207). In our dev environments, https is enabled and we use self-signed certs. It makes no sense to invest in CA signed certs for development purposes. However, once the end result gets shipped to a productive environment, strict SSL (overall) is used. Meaning, both the upstream resource as well as the authentication provider are using CA signed certs. That's why I thought it would make sense to have such an option, to be able to switch it on and off as needed based on your use case. |
|
Thanks. Helpful context. One last question, Did you evaluate l valid free certs through lets encrypt or startcom? I understand the desire not to pay for development certificates but I'm on the fence here because I am concerned about insecure production configurations. |
|
We did, but since our dev environment is internal, and can't be reached externally, it didn't seem necessary. |
No description provided.