I'm attempting to add an ingress to my AKS cluster and link that to a domain I have purchased but the site always fails to load in the browser. It doesn't matter whether I use the IP address of DNS name, it fails all the same.
I have added a DNS zone and an entry that points to a frontend IP configuration on the load balancer.
This IP corresponds to the external IP of the ingress.
I can also run a curl request which appears to return details of my react application
curl -v -k --resolve oconnorevents.co.uk:443:20.90.138.208 https://oconnorevents.co.uk
* Added oconnorevents.co.uk:443:20.90.138.208 to DNS cache
* Hostname oconnorevents.co.uk was found in DNS cache
* Trying 20.90.138.208:443...
* Connected to oconnorevents.co.uk (20.90.138.208) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=oconnorevents.co.uk; O=aks-ingress-tls
* start date: May 18 18:41:04 2021 GMT
* expire date: May 18 18:41:04 2022 GMT
* issuer: CN=oconnorevents.co.uk; O=aks-ingress-tls
* SSL certificate verify result: self signed certificate (18), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x1c41bb41a30)
> GET / HTTP/2
> Host: oconnorevents.co.uk
> user-agent: curl/7.75.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< date: Tue, 18 May 2021 22:31:05 GMT
< content-type: text/html
< content-length: 3179
< last-modified: Tue, 18 May 2021 19:15:59 GMT
< etag: "60a4126f-c6b"
< accept-ranges: bytes
< strict-transport-security: max-age=15724800; includeSubDomains
<
<!doctype html><html lang="en"><head><meta charset="utf-8"/><link rel="icon" href="/favicon.ico"/><meta name="viewport" content="width=device-width,initial-scale=1"/><meta name="theme-color" content="#000000"/><meta name="description" content="Web site created using create-react-app"/><link rel="apple-touch-icon" href="/logo192.png"/><link rel="manifest" href="/manifest.json"/><link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,400,500,700&display=swap"/><title>React App</title><link href="/static/css/main.6dea0f05.chunk.css" rel="stylesheet"></head><body><noscript>You need to enable JavaScript to run this app.</noscript><div id="root"></div><script>!function(e){function r(r){for(var n,a,i=r[0],c=r[1],l=r[2],s=0,p=[];s<i.length;s++)a=i[s],Object.prototype.hasOwnProperty.call(o,a)&&o[a]&&p.push(o[a][0]),o[a]=0;for(n in c)Object.prototype.hasOwnProperty.call(c,n)&&(e[n]=c[n]);for(f&&f(r);p.length;)p.shift()();return u.push.apply(u,l||[]),t()}function t(){for(var e,r=0;r<u.length;r++){for(var t=u[r],n=!0,i=1;i<t.length;i++){var c=t[i];0!==o[c]&&(n=!1)}n&&(u.splice(r--,1),e=a(a.s=t[0]))}return e}var n={},o={1:0},u=[];function a(r){if(n[r])return n[r].exports;var t=n[r]={i:r,l:!1,exports:{}};return e[r].call(t.exports,t,t.exports,a),t.l=!0,t.exports}a.e=function(e){var r=[],t=o[e];if(0!==t)if(t)r.push(t[2]);else{var n=new Promise((function(r,n){t=o[e]=[r,n]}));r.push(t[2]=n);var u,i=document.createElement("script");i.charset="utf-8",i.timeout=120,a.nc&&i.setAttribute("nonce",a.nc),i.src=function(e){return a.p+"static/js/"+({}[e]||e)+"."+{2:"edb3d180",4:"2f2d3220",5:"40109260"}[e]+".chunk.js"}(e);var c=new Error;u=function(r){i.onerror=i.onload=null,clearTimeout(l);var t=o[e];if(0!==t){if(t){var n=r&&("load"===r.type?"missing":r.type),u=r&&r.target&&r.target.src;c.message="Loading chunk "+e+" failed.\n("+n+": "+u+")",c.name="ChunkLoadError",c.type=n,c.request=u,t[1](c)}o[e]=void 0}};var l=setTimeout((function(){u({type:"timeout",target:i})}),12e4);i.onerror=i.onload=u,document.head.appendChild(i)}return Promise.all(r)},a.m=e,a.c=n,a.d=function(e,r,t){a.o(e,r)||Object.defineProperty(e,r,{enumerable:!0,get:t})},a.r=function(e){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},a.t=function(e,r){if(1&r&&(e=a(e)),8&r)return e;if(4&r&&"object"==typeof e&&e&&e.__esModule)return e;var t=Object.create(null);if(a.r(t),Object.defineProperty(t,"default",{enumerable:!0,value:e}),2&r&&"string"!=typeof e)for(var n in e)a.d(t,n,function(r){return e[r]}.bind(null,n));return t},a.n=function(e){var r=e&&e.__esModule?function(){return e.default}:function(){return e};return a.d(r,"a",r),r},a.o=function(e,r){return Object.prototype.hasOwnProperty.call(e,r)},a.p="/",a.oe=function(e){throw console.error(e),e};var i=this["webpackJsonpoconnorevents.react"]=this["webpackJsonpoconnorevents.react"]||[],c=i.push.bind(i);i.push=r,i=i.slice();for(var l=0;l<i.length;l++)r(i[l]);var f=c;t()}([])</script><script src="/static/js/3.5e3399a8.chunk.js"></script><script src="/static/js/main.8eab695a.chunk.js"></script></body></html>* Connection #0 to host oconnorevents.co.uk left intact
This is the details of my ingress
Name: ingress
Namespace: default
Address: 20.90.138.208
Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
aks-ingress-tls terminates oconnorevents.co.uk
Rules:
Host Path Backends
---- ---- --------
oconnorevents.co.uk
/(.*) svc-oconnorevents-react:80 (10.244.0.41:80)
Annotations: kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/rewrite-target: /$2
nginx.ingress.kubernetes.io/use-regex: true
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Sync 0s (x2 over 23s) nginx-ingress-controller Scheduled for sync
Normal Sync 0s (x2 over 23s) nginx-ingress-controller Scheduled for sync
This is the .yaml for my ingress...
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress
namespace: default
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
tls:
- hosts:
- oconnorevents.co.uk
secretName: aks-ingress-tls
rules:
- host: oconnorevents.co.uk
http:
paths:
- path: /(.*)
pathType: Prefix
backend:
service:
name: svc-oconnorevents-react
port:
number: 80
And this is the service and app that it's pointing to
apiVersion: v1
kind: Service
metadata:
name: svc-oconnorevents-react
labels:
version: dev
product: oconnorevents-react
spec:
selector:
app: oconnorevents-react
type: ClusterIP
ports:
- port: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: dep-oconnorevents-react
spec:
replicas: 1
selector:
matchLabels:
app: oconnorevents-react
template:
metadata:
labels:
app: oconnorevents-react
spec:
containers:
- name: oconnorevents-react
image: oconnorevents.azurecr.io/oconnoreventsreact:#{Build.BuildId}#
ports:
- containerPort: 80
resources:
limits:
cpu: "0.10"
imagePullSecrets:
- name: acr-secret
I feel I am close but where am I going wrong here?
What kind of error are you getting when accessing via a browser?
The curl request is succeeding because you’re explicitly ignoring the self-signed certificate with ‘-k’.
Related
Over all description of what I am doing: I am using a private nginx ingress controller in AKS (Azure Kubernetes Service) and setting up Secrets Store CSI Driver to enable NGINX Ingress Controller with TLS using this doc: Doc1
Following are the steps I am doing as per the doc:
Deploying Secrets provider:
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: azure-tls
spec:
provider: azure
secretObjects: # secretObjects defines the desired state of synced K8s secret objects
- secretName: ingress-tls-csi
type: kubernetes.io/tls
data:
- objectName: <CertName>
key: tls.key
- objectName: <CertName>
key: tls.crt
parameters:
usePodIdentity: "false"
useVMManagedIdentity: "true"
userAssignedIdentityID: <GUIDForManagedIdentityProviderHavingAccessToKeyvault>
keyvaultName: <KeyvaultName> # the name of the AKV instance
objects: |
array:
- |
objectName: <CertName>
objectType: secret
tenantId: <GUIDForKeyVaultTenant> # the tenant ID of the AKV instance
Deploying a private nginx ingress controller using this documentation: Doc2
helm upgrade nginx-ingress ingress-nginx/ingress-nginx `
--install `
--version 4.1.3 `
--namespace ingress-nginx `
--set controller.replicaCount=2 `
--set controller.nodeSelector."kubernetes\.io/os"=linux `
--set controller.image.registry="ashwin.azurecr.io" `
--set controller.image.image="ingress-nginx/controller" `
--set controller.image.tag="v1.2.1" `
--set controller.image.digest="" `
--set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux `
--set controller.admissionWebhooks.patch.image.registry="ashwin.azurecr.io" `
--set controller.admissionWebhooks.patch.image.image="ingress-nginx/kube-webhook-certgen" `
--set controller.admissionWebhooks.patch.image.tag="v1.1.1" `
--set controller.admissionWebhooks.patch.image.digest="" `
--set defaultBackend.nodeSelector."kubernetes\.io/os"=linux `
--set defaultBackend.image.registry="ashwin.azurecr.io" `
--set defaultBackend.image.image="defaultbackend-amd64" `
--set defaultBackend.image.tag="1.5" `
--set defaultBackend.image.digest="" `
-f "..\..\manifests\internal-controller-tls.yaml" --debug
The ..\..\manifests\internal-controller-tls.yaml file has this content:
controller:
service:
loadBalancerIP: 10.0.0.11
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path: "/healthz"
extraVolumes:
- name: secrets-store-inline
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: "azure-tls"
extraVolumeMounts:
- name: secrets-store-inline
mountPath: "/mnt/secrets-store"
readOnly: true
Deployed the ingress having this configuration( Picked from here Doc1):
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: healthcheck-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
ingressClassName: nginx
tls:
- hosts:
- ingress.cluster.apaca.demo.com
secretName: ingress-tls-csi
rules:
- host: ingress.cluster.apaca.demo.com
http:
paths:
- path: /cluster-ingress-healthz(/|$)(.*)
pathType: Prefix
backend:
service:
name: service1
port:
number: 80
- path: /(.*)
pathType: Prefix
backend:
service:
name: service2
port:
number: 80
After following the 3 steps I am seeing 308 Permanent Redirect when i do a curl command to the http endpoint of the ingress:
azadmin#acs-apaca-aksVm:~$ curl -v http://ingress.cluster.apaca.demo.com
* Rebuilt URL to: http://ingress.cluster.apaca.demo.com/
* Trying 10.0.0.11...
* TCP_NODELAY set
* Connected to ingress.cluster.apaca.demo.com (10.0.0.11) port 80 (#0)
> GET / HTTP/1.1
> Host: ingress.cluster.apaca.demo.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 308 Permanent Redirect
< Date: Thu, 14 Jul 2022 04:28:53 GMT
< Content-Type: text/html
< Content-Length: 164
< Connection: keep-alive
< Location: https://ingress.cluster.apaca.demo.com
<
<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host ingress.cluster.apaca.demo.com left intact
azadmin#acs-apaca-aksVm:~$
But when i put this additional annotation in kubernetes ingress, nginx.ingress.kubernetes.io/ssl-redirect: "false" the http endpoint shows the correct content
This is what i see when i do a curl to the http ingress endpoint:
azadmin#acs-apaca-aksVm:~$ curl -v http://ingress.cluster.apaca.demo.com
* Rebuilt URL to: http://ingress.cluster.apaca.demo.com/
* Trying 10.0.0.11...
* TCP_NODELAY set
* Connected to ingress.cluster.apaca.demo.com (10.0.0.11) port 80 (#0)
> GET / HTTP/1.1
> Host: ingress.cluster.apaca.demo.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 14 Jul 2022 04:33:34 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 617
< Connection: keep-alive
<
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<link rel="stylesheet" type="text/css" href="/static/default.css">
<title>WELCOME TO AZURE KUBERNETES SERVICE</title>
<script language="JavaScript">
function send(form){
}
</script>
</head>
<body>
<div id="container">
<form id="form" name="form" action="/"" method="post"><center>
<div id="logo">WELCOME TO AZURE KUBERNETES SERVICE</div>
<div id="space"></div>
<img src="/static/acs.png" als="acs logo">
<div id="form">
</div>
</div>
</body>
* Connection #0 to host ingress.cluster.apaca.demo.com left intact
</html>azadmin#acs-apaca-aksVm:~$
but with the additional annotation of nginx.ingress.kubernetes.io/ssl-redirect: "false" the requests will only be http. When i do a curl to the https endpoint for ingress.. I see this in both the cases (case 1: Annotation not added to the ingress, case 2: Annotation added to the ingress).
azadmin#acs-apaca-aksVm:~$ curl -v https://ingress.cluster.apaca.demo.com
* Rebuilt URL to: https://ingress.cluster.apaca.demo.com/
* Trying 10.0.0.11...
* TCP_NODELAY set
* Connected to ingress.cluster.apaca.demo.com (10.0.0.11) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* stopped the pause stream!
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
azadmin#acs-apaca-aksVm:~$
Please help me understand what should I change here so that the 308 redirects error go away and I can have successfull https connected to the ingress endpoint
I have a barebone simple example that works locally but not in Azure. My original question was a bit specific to an cors-error, that i have now worked around, and therefor edited away that part. But i still cant manage to make WS work on azure. And i need help.;
var server = http.Server(app);
const wss = new WebSocket.Server({server});
server.listen(8070, () => {
console.log("Listening on " + port)
});
wss.on('connection', (socket) => {
console.log('a user connected');
socket.on('message', (msg) => {
console.log(msg)
socket.send(JSON.stringify({hey:'you'}))
})
});
client connection-string:
SOCKET_ENDPOINT = 'wss://******.azurewebsites.net/';
I've turned on websockets in my app-configuration.
EDIT:
So i have now turned every stone. Even switched library from socket.io to ws. Same problem. I came a little further i think when trying different things, now i get following error "Firefox can’t establish a connection to the server at wss://*******.azurewebsites.net:8070/."
Edit2:
The http-upgrade is fine
Here's the error
Edit 3: Curl command:
* TCP_NODELAY set
* Connected to *******.azurewebsites.net (20.40.202.6) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (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, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=*.azurewebsites.net
* start date: Sep 28 19:00:01 2020 GMT
* expire date: Sep 28 19:00:01 2021 GMT
* subjectAltName: host "********.azurewebsites.net" matched cert's "*.azurewebsites.net"
* issuer: C=US; O=Microsoft Corporation; CN=Microsoft RSA TLS CA 01
* SSL certificate verify ok.
> GET /socket.io/?EIO=4 HTTP/1.1
> Host: *********.azurewebsites.net
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Server: Kestrel
< WWW-Authenticate: Bearer realm="********.azurewebsites.net" authorization_uri="https://login.windows.net/<tenant>/oauth2/authorize" resource_id="<resource>"
< Date: Tue, 22 Jun 2021 05:56:15 GMT
< Content-Length: 0
<
* Connection #0 to host *******.azurewebsites.net left intact
I am guessing that you host your app in Azure AppService?
Make sure you have websocket option turned on in platform:
AppService resource -> Settings -> General settings tab -> Platform settings section
I have previously deployed a lot of services to Cloud Run but this is my first time deploying a NodeJs server. It got successfully deployed and is also working perfectly. The problem arises when I map a custom domain to it. It works with the generated URL but not with the mapped URL. Whenever I hit the mapped URL, it returns 400 Bad Request
My NodeJS code:
const app = require('express')();
const cors = require('cors');
const server = require('http').createServer(app);
// routes
const home = require('./src/routes');
app.use(cors());
app.use('/', home);
const PORT = process.env.PORT || 5000;
server.listen(PORT, '0.0.0.0', () => console.log(`Server listening on port ${PORT}`));
Dockerfile
FROM node:16
# Create app directory
WORKDIR /usr/src/app
# Install app dependencies
# A wildcard is used to ensure both package.json AND package-lock.json are copied
# where available (npm#5+)
COPY package*.json ./
# If you are building your code for production
RUN npm ci --only=production
# Bundle app source
COPY . .
EXPOSE 5000
CMD [ "node", "server.js" ]
Curl
curl -v https://<subdomain.domain.com>
* Trying 17x.xxx.xxx.xxx:443...
* TCP_NODELAY set
* Connected to <subdomain.domain.com> (17x.xxx.xxx.xxx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=<subdomain.domain.com>
* start date: May 29 15:31:03 2021 GMT
* expire date: Aug 27 16:31:03 2021 GMT
* subjectAltName: host "<subdomain.domain.com>" matched cert's "<subdomain.domain.com>"
* issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1D4
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x565480c42e10)
> GET / HTTP/2
> Host: <subdomain.domain.com>
> user-agent: curl/7.68.0
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 400
< content-type: text/html
< x-content-type-options: nosniff
< referrer-policy: same-origin
< x-cloud-trace-context: d0038e2821f61d26f77c95ead4f75d96
< date: Mon, 31 May 2021 19:54:12 GMT
< server: Google Frontend
< content-length: 143
<
<!doctype html>
<html lang="en">
<head>
<title>Bad Request (400)</title>
</head>
<body>
<h1>Bad Request (400)</h1><p></p>
</body>
</html>
* Connection #0 to host <subdomain.domain.com> left intact
I’m running into an issue with axios and Node 12. As I’m not sure this error is only related to axios, I followed the advice to ask on SO rather than opening a bug on axios’ GitHub.
Here is the code I’m trying to run :
const axios = require('axios')
axios({
method: 'get',
url: 'https://www.colisprive.com/moncolis/pages/detailColis.aspx?numColis=12345',
responseType: 'text'
}).then((response) => {
console.log(response)
})
This code fails on Node 12 with following error :
Error: write EPROTO 140121214769024:error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol:../deps/openssl/openssl/ssl/statem/statem_lib.c:1929:
at WriteWrap.onWriteComplete [as oncomplete] (internal/stream_base_commons.js:87:16)
Same code ran against Node 11 doesn’t throw any error.
When I curl -v I got this :
* Trying 91.208.224.32:443...
* TCP_NODELAY set
* Connected to www.colisprive.com (91.208.224.32) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (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, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: serialNumber=391029345; jurisdictionC=FR; businessCategory=Private Organization; C=FR; postalCode=13290; ST=Bouches-du-Rh�ne; L=AIX EN PROVENCE; street=1330 AV J R G GAUTIER DE LA LAUZIERE; street=ZI MILLES EUROPARC PICHAURY; O=COLIS PRIVE SAS; OU=0002 391029345; CN=www.colisprive.com
* start date: Sep 3 00:00:00 2018 GMT
* expire date: Sep 2 23:59:59 2020 GMT
* subjectAltName: host "www.colisprive.com" matched cert's "www.colisprive.com"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Extended Validation Secure Server CA
* SSL certificate verify ok.
> GET /moncolis/pages/detailColis.aspx?numColis=12345 HTTP/1.1
> Host: www.colisprive.com
> User-Agent: curl/7.65.3
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Cache-Control: private
< Content-Type: text/html; charset=utf-8
< Location: /moncolis/Default.aspx?numColis=12345&cp=
< Server: Microsoft-IIS/7.5
< Set-Cookie: ASP.NET_SessionId=eln3cq143d35lfj5tpqkkwcg; path=/; HttpOnly
< X-Powered-By: Colis Priv�
< Date: Fri, 24 Jan 2020 13:48:35 GMT
< Content-Length: 162
<
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
* Connection #0 to host www.colisprive.com left intact
As you can see, it gives a 302 Found with a Location header pointing to another endpoint. I agree it should answer a 301 Moved to indicate document has moved, but this is not the case and it is handled as expected by axios on Node 11 (fetching endpoint under Location header).
I saw that Node 12 now includes TLS 1.3 as default, so this could be related to that…
Also, there is an unknown character in X-Powered-By header.
I tried to :
reproduce this issue with an express server always replying 302 Found with same headers : works as expected
fetch another .aspx web page with axios : works as expected
The problem is not just with axios but with got as well.
Node.js 12's default TLS settings are stricter now. The site doesn't handle TLS v1.2. Node 12 by default need 1.2.
You can change this via a command line flag (--tls-min-v1.0) when running your app.
something like this
node --tls-min-v1.0 app.js
Cloud Provider: Azure
Istio Version: 1.19
Kubernetes Version: 1.12.8
Below is my Virtual Service and Gateway yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: app-ingress-rules
namespace: istio-system
# Define the routes less restrictive first to more restrictive. this file gets read from bottom to top.
spec:
# https://istio.io/docs/reference/config/istio.networking.v1alpha3/#VirtualService
gateways: # The default `mesh` value for when left blank is doesn't seem to propigate the rule properly. For now, always use a list of FQDN gateways
- tls-gateway
hosts:
- "dev.myapp.westus.cld.something.com" # This host is part of installed HTTPS cert
- "nonprod.westus.cloudapp.azure.com" # This host is NOT part of installed HTTPS cert
http:
# Routes
- match:
- uri:
prefix: /myapp/status
rewrite:
uri: /status
route:
- destination:
host: myapp.myapp-ns.svc.cluster.local
--------------------------------------------
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: tls-gateway
namespace: istio-system
spec:
selector:
istio: ingressgateway
servers:
- port:
name: https
number: 443
protocol: HTTPS
tls:
mode: SIMPLE
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
privateKey: /etc/istio/ingressgateway-certs/tls.key
hosts:
- "*"
If I do
curl -Iv https://dev.myapp.westus.cld.something.com/myapp/status
I get HTTP 404 as below
* Trying 123.12.123.12...
* TCP_NODELAY set
* Connected to dev.myapp.westus.cld.something.com (123.12.123.12.) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* 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-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=***; L=*****; O=******, Inc.; CN=*********
* start date: Jul 26 20:32:59 2019 GMT
* expire date: Jul 26 20:32:59 2021 GM
* subjectAltName: host "dev.myapp.westus.cld.something.com" matched cert's "dev.myapp.westus.cld.something.com"
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA OV SSL CA 2018
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f995e006600)
> HEAD /myapp/status HTTP/2
> Host: dev.myapp.westus.cld.something.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 404
HTTP/2 404
< location: https://dev.myapp.westus.cld.something.com/myapp/status
location: https://dev.myapp.westus.cld.something.com /myapp/status
< date: Wed, 31 Jul 2019 19:10:13 GMT
date: Wed, 31 Jul 2019 19:10:13 GMT
< server: istio-envoy
server: istio-envoy
<
* Connection #0 to host dev.myapp.westus.cld.something.com left intact
However when I try with
curl -Iv --insecure https://nonprod.westus.cloudapp.azure.com/myapp/status
I get HTTP 200. see below
* Trying 123.12.123.12...
* TCP_NODELAY set
* Connected to nonprod.westus.cloudapp.azure.com (123.12.123.12) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection:
ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* 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-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=****; L=*****; O=******, Inc.; CN=*********
* start date: Jul 26 20:32:59 2019 GMT
* expire date: Jul 26 20:32:59 2021 GMT
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA OV SSL CA 2018
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fb4b7003c00)
> HEAD /myapp/status HTTP/2
> Host: nonprod.westus.cloudapp.azure.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
HTTP/2 200
< request-context: appId=cid-v1:39296fe8-1dc6-4049-bb31-e7816e83b9ec
request-context: appId=cid-v1:39296fe8-1dc6-4049-bb31-e7816e83b9ec
< access-control-allow-origin: *
access-control-allow-origin: *
< access-control-expose-headers: Content-Disposition
access-control-expose-headers: Content-Disposition
< content-type: text/plain;charset=ISO-8859-1
content-type: text/plain;charset=ISO-8859-1
< content-length: 69
content-length: 69
< date: Wed, 31 Jul 2019 19:07:54 GMT
date: Wed, 31 Jul 2019 19:07:54 GMT
< x-envoy-upstream-service-time: 7
x-envoy-upstream-service-time: 7
< server: istio-envoy
server: istio-envoy
<
* Connection #0 to host nonprod.westus.cloudapp.azure.com left intact
Is my VS configuration wrong with regards to accepting HTTPS traffic? I am unable to look at envoy logs to see if there is any error.
How can I pinpoint where the issue is?
Update
dev.myapp.westus.cld.something.com is a CName record which ultimately points to nonprod.westus.cloudapp.azure.com
nonprod.westus.cloudapp.azure.com is a actual DNS which is mapped to a public IP.
Note sure if that makes any difference.