I am following https://blogs.technet.microsoft.com/livedevopsinjapan/2017/02/28/configure-nginx-ingress-controller-for-tls-termination-on-kubernetes-on-azure-2/ to make TLS termination works on Azure. After everything is setup, I can access the server successfully. However, I always got the fake certificate instead of my own certificate.
It seems the certificate was loaded properly
$ kubectl -n kube-system logs nginx-ingress-controller-2781903634-hf1xv
[dumb-init] Unable to detach from controlling tty (errno=25 Inappropriate ioctl for device).
[dumb-init] Child spawned with PID 6.
[dumb-init] Unable to attach to controlling tty (errno=25 Inappropriate ioctl for device).
[dumb-init] setsid complete.
I0730 20:15:38.652971 6 launch.go:105] &{NGINX 0.9.0-beta.11 git-a3131c5 https://github.com/kubernetes/ingress}
I0730 20:15:38.653062 6 launch.go:108] Watching for ingress class: nginx
I0730 20:15:38.653322 6 launch.go:262] Creating API server client for https://10.0.0.1:443
I0730 20:15:38.654313 6 nginx.go:182] starting NGINX process...
I0730 20:15:38.705427 6 launch.go:124] validated kube-system/default-http-backend as the default backend
I0730 20:15:38.753788 6 controller.go:1190] starting Ingress controller
I0730 20:15:38.756999 6 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"nginx-test", UID:"b04eaf16-7558-11e7-8ff6-000d3ad09dba", APIVersion:"extensions", ResourceVersion:"20007", FieldPath:""}): type: 'Normal' reason: 'CREATE' Ingress default/nginx-test
I0730 20:15:38.854114 6 leaderelection.go:203] attempting to acquire leader lease...
I0730 20:15:38.855431 6 backend_ssl.go:64] adding secret default/tls-secret to the local store
I0730 20:15:39.190589 6 controller.go:428] backend reload required
I0730 20:15:39.190690 6 metrics.go:34] changing prometheus collector from to default
I0730 20:15:39.238664 6 controller.go:438] ingress backend successfully reloaded...
I0730 20:16:14.095774 6 leaderelection.go:213] successfully acquired lease kube-system/ingress-controller-leader-nginx
I0730 20:16:38.886648 6 status.go:310] updating Ingress default/nginx-test status to [{10.240.0.5 }]
I0730 20:16:38.915168 6 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"nginx-test", UID:"b04eaf16-7558-11e7-8ff6-000d3ad09dba", APIVersion:"extensions", ResourceVersion:"20334", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress default/nginx-test
127.0.0.1 - [127.0.0.1] - - [30/Jul/2017:20:21:58 +0000] "GET / HTTP/2.0" 200 1001 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36" 270 0.004 [default-http-svc-80] 10.244.2.8:8080 1252 0.004 200
127.0.0.1 - [127.0.0.1] - - [30/Jul/2017:20:22:01 +0000] "GET /favicon.ico HTTP/2.0" 200 971 "https://40.126.253.219/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36" 67 0.000 [default-http-svc-80] 10.244.0.8:8080 1244 0.000 200
I tried the two steps below but the issue still persists and got similar logs.
quay.io/aledbf/nginx-ingress-controller:0.171 to replace gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.11Any suggestion is appreciated. Thank you in advance.
I'm encountering the same problem, but it's universal regardless of what certificate I attempt to install through the secret. I was attempting to get a certificate from a CA functioning and it was not verifying. I eventually found that the controller was serving up the Kubernetes Ingress Controller Fake Certificate.
openssl s_client -showcerts -connect <redacted>:443 </dev/null
CONNECTED(00000003)
depth=0 O = Acme Co, CN = Kubernetes Ingress Controller Fake Certificate
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 O = Acme Co, CN = Kubernetes Ingress Controller Fake Certificate
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/O=Acme Co/CN=Kubernetes Ingress Controller Fake Certificate
i:/O=Acme Co/CN=Kubernetes Ingress Controller Fake Certificate
-----BEGIN CERTIFICATE-----
MIIDcDCCAligAwIBAgIRAIDt5DuCRLfHy35tpVYxpywwDQYJKoZIhvcNAQELBQAw
SzEQMA4GA1UEChMHQWNtZSBDbzE3MDUGA1UEAxMuS3ViZXJuZXRlcyBJbmdyZXNz
IENvbnRyb2xsZXIgRmFrZSBDZXJ0aWZpY2F0ZTAeFw0xNzA4MTYxMzIzMThaFw0x
ODA4MTYxMzIzMThaMEsxEDAOBgNVBAoTB0FjbWUgQ28xNzA1BgNVBAMTLkt1YmVy
bmV0ZXMgSW5ncmVzcyBDb250cm9sbGVyIEZha2UgQ2VydGlmaWNhdGUwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFQROFitnJSePmaJ2POrehCWn6nzaA
gi12RXHVKtWGxqlf6vueHelLV7iozJ2nN0qeZXUUZHQJs5NknHw0CDYgDHTA4TvQ
mdjypuRsBSPIAPZPWUxqF5ZGLzVrABatcjfBBS1mWiccZ+N4DgpWEgaghKXNUlEe
awu8kePNgN8KtZDWsKtr7SlVXFZwb3SuPrYiU3oSf5PeKbW3hCDNyssE+2lUrqB2
KPN5fhsbwukh7dM3mjHh3XBotzEcXFsSmg94veQyfBH5phVF1WGFXyiOeoxXn2/M
zWqyOxqEffb2WxX0Fr5riz6smafAgggJHhV3uipLie7YqBOMzhY9EDT5AgMBAAGj
TzBNMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDATAMBgNVHRMB
Af8EAjAAMBgGA1UdEQQRMA+CDWluZ3Jlc3MubG9jYWwwDQYJKoZIhvcNAQELBQAD
ggEBAIX+LNWO8X18sOX9Hc6Lyw/q3rJO5ydxRP8fMuFvm5PC5BToevdH0ZN5BxOT
q75zcJ0Xv3JIvv9BsAIXCNhhO0sqlN/6SLqx+MMtC5IdfwyxmZNloyaL5dMgT4Mv
sMxoSpAHgmc8oeoN/V3C/SGCn8vh7GJeSnjnnBr+gXV7PCHfZnnBAsqvI5wv8YUU
gbzXiA3mu5n9xk5k1xPLc2xC6gkLUflqt8hLGlRjCc5UtEiGgn8dMvrp3OEpiVyB
ww9GJOAlQZb1ra8p/vWOF4adzCnLYRGz5WEWAd5Y9JOkta/61yv179zC3ojJ2MRw
Tktp3Nbvg7HlaFj93xEE9dcxzCA=
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Acme Co/CN=Kubernetes Ingress Controller Fake Certificate
issuer=/O=Acme Co/CN=Kubernetes Ingress Controller Fake Certificate
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 1591 bytes and written 463 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 32BCD0057D5D2AA4F8E265DDE546E50CCBE8E1DBFA33BBB07568E1117A394026
Session-ID-ctx:
Master-Key: 415B9F329663C3E04001CF020A399572100D1BF6A40D3B7C630592F72C5478F8D8B8BE7AE49303CD3FD1E95094ADA2AC
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 600 (seconds)
TLS session ticket:
0000 - dc de ea 16 e1 c3 22 9a-48 3a 0e 46 dc 9f 20 10 ......".H:.F.. .
0010 - c8 c7 51 af 5c 2e f9 f6-16 2e 00 c7 17 ef a0 f3 ..Q.\...........
0020 - 34 e2 44 fb 18 36 2d 2d-45 3c 9b b0 df 56 9a 85 4.D..6--E<...V..
0030 - 8e 6d ec 53 8a 92 11 59-23 93 96 dd a4 c4 e2 5a .m.S...Y#......Z
0040 - d2 de 93 af ba 4d af 57-21 18 27 08 aa a8 96 8f .....M.W!.'.....
0050 - e8 18 23 f8 3d 77 84 a8-aa 72 5c 7b e8 86 15 d9 ..#.=w...r\{....
0060 - 90 1d 88 95 5e 9f 40 45-9f db ea a9 85 8f e3 17 ....^.@E........
0070 - 1f 39 a5 6f 60 e0 b1 c4-f1 1f b3 74 6b e6 ee 65 .9.o`......tk..e
0080 - b6 8e 16 df 0c 79 86 ab-65 52 3e 3f a2 02 d0 16 .....y..eR>?....
0090 - 09 14 93 41 6c f8 33 0b-7c 61 d2 83 43 06 38 5d ...Al.3.|a..C.8]
00a0 - ab 3b ed 2f e7 d8 c1 2e-42 c5 71 dc 8c 21 8f 0c .;./....B.q..!..
Start Time: 1502891093
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
DONE
At the time, I had assumed there was something wrong with my procedure installing the certificate, so I resorted to following the tutorial mentioned by @xuehung to see if I could get that working. I ended up encountering the same fake certificate problem there as well. I subsequently tried using the controller from quay.io/aledbf/nginx-ingress-controller:0.180 but the same error persisted.
I don't think this is an Azure specific issue since the certificate is being served up from the Ingress controller, but I guess I wouldn't rule it out. Either way, as far as I can see, it's either not currently possible to TLS terminate with the current versions of the nginx ingress controller or there is something lacking in the instructions I am utilizing.
@shawnmcknight please update the image to quay.io/aledbf/nginx-ingress-controller:0.180
@shawnmcknight how are you running the controller?
@shawnmcknight please update the image to quay.io/aledbf/nginx-ingress-controller:0.180
@aledbf I had already tried using quay.io/aledbf/nginx-ingress-controller:0.180 and encountered the same fake certificate issue as when I used gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.11.
@shawnmcknight how are you running the controller?
I'm not exactly sure what this question means, but I will try my best to answer it. If you're looking for something else other than what I say here, please let me know.
I am using the examples/deployment/nginx-ingress-controller.yaml file along with kubectl apply -f nginx-ingress-controller.yaml. Once the controller has successfully deployed, I expose it as a service with kubectl expose rs nginx-ingress-controller-3752011415 --port=443 --target-port=443 --name=nginx-ingress-ssl --type=LoadBalancer --namespace kube-system where nginx-ingress-controller-3752011415 is the name of the Replica Set that was created when the controller was deployed.
Once that happens, Azure creates the public facing load balancer after a few minutes and assigns a public IP to it. The service then shows exposed on that IP.
Lastly, I create the ingress using the examples/tls-termination/nginx-tls-ingress.yaml by kubectl create -f nginx-tls-ingress.yaml. I had earlier created a tls-secret by following the instructions in PREREQUISITES.md as well as created the test http-svc.
The ingress works properly to route to the http-svc, but the certificate is not the one I had generated and stored in the tls-secret, It is the Kubernetes Ingress Controller Fake Certificate instead.
Please let me know if I can clarify anything or provide any additional details.
ETA: I had also updated the nginx-ingress-controller.yaml file in my most recent test to use the image at quay.io/aledbf/nginx-ingress-controller:0.180.
@shawnmcknight let me start a cluster in azure and follow your steps.
What k8s version are you using? How did you installed the cluster? Is RBAC enabled?
@aledbf I'm deploying in Azure using the latest acs-engine and following the steps laid out at https://github.com/Azure/acs-engine/blob/master/docs/kubernetes/deploy.md.
The engine appears to deploy with k8s 1.6.6 using this method.
I'm not sure if RBAC is enabled and I didn't see how to check on cursory Google search. I did not personally do anything to enable or disable is, so whatever the defaults or whatever acs-engine does on deployment would be how it currently is.
Thanks!
I'm admittedly tinkering with things that I'm a real novice at, but from what I can see, the nginx.conf in the running pod doesn't appear to be referencing the secret that I created.
I entered bash in my running controller pod by doing kubectl exec nginx-ingress-controller-170554507-6hrd0 -n kube-system -it bash and inspected /etc/nginx/nginx.conf which appears to have been configured to route traffic to the http-svc pod which leads me to believe this is the underpinnings of how this controller works. However, the ssl_certificate and ssl_certificate_key directives are pointing to the default-fake-certificate and not the secret that the ingress indicates it should:
upstream default-http-svc-80 {
# Load balance algorithm; empty for round robin, which is the default
least_conn;
server 10.244.0.5:8080 max_fails=0 fail_timeout=0;
}
server {
server_name _;
listen 80 default_server reuseport backlog=511;
listen [::]:80 default_server reuseport backlog=511;
set $proxy_upstream_name "-";
listen 442 proxy_protocol default_server reuseport backlog=511 ssl http2;
listen [::]:442 proxy_protocol default_server reuseport backlog=511 ssl http2;
# PEM sha: 0c75b519f233303693b25c580bddde76465e505f
ssl_certificate /ingress-controller/ssl/default-fake-certificate.pem;
ssl_certificate_key /ingress-controller/ssl/default-fake-certificate.pem;
more_set_headers "Strict-Transport-Security: max-age=15724800; includeSubDomains;";
location / {
set $proxy_upstream_name "default-http-svc-80";
...
In /ingress-controller/ssl I can see the default-tls-secret.pem file and upon inspection I see that both my certificate and private key from the secret are present inside the file. Therefore the controller seems to be loading the certificate and key properly, but it just doesn't seem to be directing nginx.conf to use it.
Finally, running kubectl describe ing nginx-test to make sure the ingress is configured to use the appropriate secret elicits:
NAME HOSTS ADDRESS PORTS AGE
nginx-test * 10.240.0.5 80, 443 19h
C:\Users\srm\Ops Stuff>kubectl describe ing nginx-test
Name: nginx-test
Namespace: default
Address: 10.240.0.5
Default backend: default-http-backend:80 (10.244.0.3:8080)
TLS:
tls-secret terminates
Rules:
Host Path Backends
---- ---- --------
*
http-svc:80 (<none>)
Annotations:
Events: <none>
So to the best of my knowledge the ingress is configured to use the appropriate secret and the secret is getting loaded as a .pem file, but the nginx.conf isn't getting updated to utilize that .pem file.
As I mentioned earlier, I'm a novice at this stuff, but hopefully that provides some meaningful insight. Thanks again!
@shawnmcknight please post the output of kubectl logs nginx-ingress-controller-170554507-6hrd0 -n kube-system and the ingress nginx-test
please post the output of kubectl logs nginx-ingress-controller-170554507-6hrd0 -n kube-system
kubectl logs nginx-ingress-controller-170554507-6hrd0 -n kube-system
I0816 13:23:18.023146 6 launch.go:108] &{NGINX 0.9.0-beta.11 git-a2217ab1 https://github.com/aledbf/ingress}
I0816 13:23:18.023172 6 launch.go:111] Watching for ingress class: nginx
I0816 13:23:18.023337 6 launch.go:270] Creating API server client for https://10.0.0.1:443
I0816 13:23:18.024511 6 nginx.go:205] starting NGINX process...
I0816 13:23:18.094356 6 launch.go:127] validated kube-system/default-http-backend as the default backend
I0816 13:23:18.112276 6 controller.go:1256] starting Ingress controller
I0816 13:23:18.114451 6 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"nginx-test", UID:"2a7fcb47-8204-11e7-88e9-000d3a1a2569", APIVersion:"extensions", ResourceVersion:"81234", FieldPath:""}): type: 'Normal' reason: 'CREATE' Ingress default/nginx-test
I0816 13:23:18.213235 6 backend_ssl.go:58] adding secret default/tls-secret to the local store
I0816 13:23:18.213398 6 leaderelection.go:174] attempting to acquire leader lease...
I0816 13:23:18.351402 6 controller.go:423] backend reload required
I0816 13:23:18.351920 6 metrics.go:34] changing prometheus collector from to default
I0816 13:23:18.405449 6 controller.go:432] ingress backend successfully reloaded...
I0816 13:23:53.342324 6 leaderelection.go:184] successfully acquired lease kube-system/ingress-controller-leader-nginx
I0816 13:24:18.237719 6 status.go:347] updating Ingress default/nginx-test status to [{10.240.0.5 }]
I0816 13:24:18.261281 6 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"nginx-test", UID:"2a7fcb47-8204-11e7-88e9-000d3a1a2569", APIVersion:"extensions", ResourceVersion:"81688", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress default/nginx-test
127.0.0.1 - [127.0.0.1] - - [16/Aug/2017:13:34:31 +0000] "GET / HTTP/1.1" 200 655 "-" "curl/7.47.0" 76 0.001 [default-http-svc-80] 10.244.0.5:8080 655 0.001 200
127.0.0.1 - [127.0.0.1] - - [16/Aug/2017:13:35:49 +0000] "GET / HTTP/1.1" 200 655 "-" "curl/7.47.0" 76 0.000 [default-http-svc-80] 10.244.0.5:8080 655 0.000 200
10.240.255.5 - [10.240.255.5] - - [16/Aug/2017:17:28:55 +0000] "GET / HTTP/1.1" 301 185 "-" "curl/7.47.0" 74 0.000 [default-http-svc-80] - - - -
127.0.0.1 - [127.0.0.1] - - [16/Aug/2017:17:29:03 +0000] "GET / HTTP/1.1" 200 649 "-" "curl/7.47.0" 74 0.000 [default-http-svc-80] 10.244.0.5:8080 649 0.000 200
and the ingress nginx-test
I'm not sure what you're asking for here as I'm unable to get kubectl to present logs for the ingress itself. The ingress' yaml definition is:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-test
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
tls:
# This assumes tls-secret exists.
- secretName: tls-secret
rules:
- http:
paths:
- backend:
# This assumes http-svc exists and routes to healthy endpoints.
serviceName: http-svc
servicePort: 80
Let me know if you're looking for something other than that. Thank you again.
@shawnmcknight ok, I see the isue. You need to specify the host in the tls section. Without that the controller does not know which host you are configuring.
@aledbf OK, so after your last comment, I tried a variety of things and it would appear from what I can see that the example at examples/tls-termination/nginx/nginx-tls-ingress.yaml may be out-of-date or just wrong as it does not indicate the need for a host specification in the tls configuration.
I was able to get the configuration to work by using a certificate that had the specified host, putting the host in the tls configuration, and having that same host be present in the rules array. When all three of these were done then the nginx.conf ended up with a server designation that properly routed.
If my understanding is correct and that all of those are necessary in order to get the proper certificate then I think the answer to the OP's (@xuehung) issue is that the tutorial he is using models tls but will not use the generated certificate. Additionally, the example in this repository might need to be corrected and/or updated. That may possibly close this issue.
As far as my issue is concerned, I've got everything working now and thank you for your assistance!
This are the required steps:
This assumes the command acs-engine deploy returns without issues.
Check k8s version:
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.0", GitCommit:"fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState:"clean", BuildDate:"2017-03-28T16:36:33Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.6", GitCommit:"7fa1c1756d8bc963f1a389f4a6937dc71f08ada2", GitTreeState:"clean", BuildDate:"2017-06-16T18:21:54Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}
Create the nginx ingress controller:
$ kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress/master/examples/deployment/nginx/nginx-ingress-controller.yaml
deployment "nginx-ingress-controller" created
$ kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress/master/examples/deployment/nginx/default-backend.yaml
deployment "default-http-backend" created
service "default-http-backend" created
$ kubectl get deployment -n kube-system
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
default-http-backend 1 1 1 1 4m
heapster 1 1 1 1 7m
kubernetes-dashboard 1 1 1 1 7m
nginx-ingress-controller 1 1 1 1 4m
tiller-deploy 1 1 1 1 7m
Create service:
$ echo "
apiVersion: v1
kind: Service
metadata:
name: nginx-ingress-controller
namespace: kube-system
spec:
type: LoadBalancer
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP
- name: https
port: 443
targetPort: 443
protocol: TCP
selector:
k8s-app: nginx-ingress-controller
" | kubectl create -f -
service "nginx-ingress-controller" created
Create SSL certificate for host foo.bar.com:
$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=foo.bar.com/O=nginxsvc"
Generating a 2048 bit RSA private key
.......+++
...+++
writing new private key to 'tls.key'
-----
$ kubectl create secret tls tls-secret --key tls.key --cert tls.crt
secret "tls-secret" created
Create echo headers service:
$ kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress/master/examples/http-svc.yaml
service "http-svc" created
replicationcontroller "http-svc" created
Get the public IP:
$ kubectl get svc -n kube-system
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default-http-backend 10.0.60.77 <none> 80/TCP 8m
heapster 10.0.39.2 <none> 80/TCP 11m
kube-dns 10.0.0.10 <none> 53/UDP,53/TCP 11m
kubernetes-dashboard 10.0.128.35 <nodes> 80:30463/TCP 11m
nginx-ingress-controller 10.0.152.168 52.175.251.222 80:30694/TCP,443:30898/TCP 3m
tiller-deploy 10.0.68.250 <none> 44134/TCP 11m
```to get
**Create the ingress rule:**
```console
echo "
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-test
annotations:
kubernetes.io/ingress.class: nginx
spec:
tls:
- hosts:
- foo.bar.com
secretName: tls-secret
rules:
- http:
paths:
- backend:
serviceName: http-svc
servicePort: 80
" | kubectl create -f -
Test the ingress:
$ curl -v http://52.175.251.222
$ curl -v http://52.175.251.222
* Rebuilt URL to: http://52.175.251.222/
* Trying 52.175.251.222...
* TCP_NODELAY set
* Connected to 52.175.251.222 (52.175.251.222) port 80 (#0)
> GET / HTTP/1.1
> Host: 52.175.251.222
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Server: nginx/1.13.3
< Date: Wed, 16 Aug 2017 20:06:45 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 21
< Connection: keep-alive
< Strict-Transport-Security: max-age=15724800; includeSubDomains;
<
* Curl_http_done: called premature == 0
* Connection #0 to host 52.175.251.222 left intact
Test if a HTTPS request returns the certificate:
$ curl -v -k --resolve foo.bar.com:443:52.175.251.222 https://foo.bar.com
* Added foo.bar.com:443:52.175.251.222 to DNS cache
* Rebuilt URL to: https://foo.bar.com/
* Hostname foo.bar.com was found in DNS cache
* Trying 52.175.251.222...
* TCP_NODELAY set
* Connected to foo.bar.com (52.175.251.222) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=foo.bar.com; O=nginxsvc
* start date: Aug 16 20:00:07 2017 GMT
* expire date: Aug 16 20:00:07 2018 GMT
* issuer: CN=foo.bar.com; O=nginxsvc
* SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET / HTTP/1.1
> Host: foo.bar.com
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.13.3
< Date: Wed, 16 Aug 2017 20:10:46 GMT
< Content-Type: text/plain
< Transfer-Encoding: chunked
< Connection: keep-alive
< Strict-Transport-Security: max-age=15724800; includeSubDomains;
<
Hostname: http-svc-qsfgt
Pod Information:
node name: k8s-agentpool1-16034652-1
pod name: http-svc-qsfgt
pod namespace: default
pod IP: 10.244.1.4
Server values:
server_version=nginx: 1.13.3 - lua: 10008
Request Information:
client_address=10.244.2.5
method=GET
real path=/
query=
request_version=1.1
request_uri=http://foo.bar.com:8080/
Request Headers:
accept=*/*
connection=close
host=foo.bar.com
user-agent=curl/7.52.1
x-forwarded-for=127.0.0.1
x-forwarded-host=foo.bar.com
x-forwarded-port=443
x-forwarded-proto=https
x-original-uri=/
x-real-ip=127.0.0.1
x-scheme=https
Request Body:
-no body in request-
* Curl_http_done: called premature == 0
* Connection #0 to host foo.bar.com left intact
Closing. This is working as expected.
@xuehung please check the steps
@xuehung please reopen if you still have issues after following the steps
If my understanding is correct and that all of those are necessary in order to get the proper certificate then I think the answer to the OP's (@xuehung) issue is that the tutorial he is using models tls but will not use the generated certificate.
I think the tutorial never checked the output of the https request
Hi @aledbf, I've repeatedly run your above instructions, substituting my CN cert for the self-signed foo.bar.com and still end up with the O=Acme Co; CN=Kubernetes Ingress Controller Fake Certificate on the nginx ingress controller. Is there by chance a bug in reading the cert from a secret?
@jskulavik please post the ingress rule you are using
@aledbf - Here's my rule. The svc, secret, and CN are working under proper TLS outside of k8s ingress

@jskulavik you're not using the correct syntax. Include the host option in the rules section and use correct syntax in the tls section, like so:
spec:
rules:
- host: my.cn.domain
http:
paths:
- backend:
serviceName: my-https-svc
servicePort: 80
path: /
tls:
- hosts:
- my.cn.domain
secretName: my-cn-secret
There's a fine manual as well
Thank you @pieterlange! I'm in love with that fine manual indeed, but apparently I glossed over hosts: in the rules node.
I'm still missing something. I've corrected my ingress syntax and restarted my pod, but still getting our beloved Acme cert. Editing the ingress alone should have worked, no?
Okay, all set now. Thank you very much @aledbf and @pieterlange. I'll put together some docs of what I did and either fork or submit a PR. Cheers 馃
I've one more nagging issue. Does the ing controller not return a valid path to the issuer cert? I'm getting
SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
via a working TLS controller. Should this be raised as an issue to address here in beta @aledbf?
You have to put the full certificate chain in the TLS secret.
Gotcha. I'll add that to a fork/PR too as I'm sure most looking to leverage ingress TLS will forget that as a prereq outside of the controller. Thanks again for keeping me 馃挴 @pieterlange
@aledbf Sorry for the late response. I just followed your steps and configuration. It works perfectly. Thank you very much!
Full usage of TLS section doesn't appear to be defined anywhere official.
I got it working as follows:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: terminate-ssl
annotations:
ingress.kubernetes.io/ssl-redirect: "true"
spec:
tls:
- secretName: svc-ssl
hosts:
- svc.example.com
rules:
- host: svc.example.com
http:
paths:
- path: /
backend:
serviceName: svc
servicePort: 80
Most helpful comment
Full usage of TLS section doesn't appear to be defined anywhere official.
I got it working as follows: