allow specifying custom dh param

[glerchundi]

fixes #162

[k8s-ci-robot]

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://github.com/kubernetes/kubernetes/wiki/CLA-FAQ to sign the CLA.

Once you've signed, please reply here (e.g. "I signed it!") and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[k8s-reviewable]

This change is 

[glerchundi]

I signed it!

[coveralls]

Coverage decreased (-0.4%) to 45.915% when pulling f41e8fd06d83155e987c0f7f4d8f5ce34072967c on glerchundi:master into fedf342 on kubernetes:master.

[glerchundi]

I already tested it empirically and seems to works, I pushed an image with this change in case you wanted to test yourself: quay.io/glerchundi/nginx-ingress-controller:0.9.0-beta.3

Create the dh containing secret:

apiVersion: v1
kind: Secret
metadata:
  name: lb-dhparam
type: Opaque
data:
  dhparam.pem: "...base64 encoded data..."

And the configmap with the actual secret pointer:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-conf
data:
  ssl-dh-param: "default/lb-dhparam"

Enough.

/cc @aledbf

[glerchundi]

added an example, rebased and squashed to one commit

[coveralls]

Coverage decreased (-0.4%) to 45.915% when pulling e1c1dfa on glerchundi:master into fedf342 on kubernetes:master.

[rikatz]

This is nice, indeed I've tested the also the dhparam and got this error, but forgot to check.

Just a question, is it interesting to generate a default-dh-param also, as there is a default-ssl-certificate?

This could give us to a 'more secure' default backend, but does not need to be present (it's optional).

[aledbf]

@rikatz the difference here is that we need to share the dh param if you are running multiple instances.

[aledbf]

/lgtm

[rikatz]

@aledbf yeap, but DH Param may be served for each vhost also. My doubt is that if we couldn't create this also for the default backends :)

But this is good for me now, we can improve this later :)

[aledbf]

@glerchundi thanks!