Registering 1st User I get Failed to Fetch Error

Hi @shiangoli

Is there a more detailed error message to be found within the console of your browser’s developer tools?

Hi @iainsproat the issue was with my domain name in the values file. I changed it to include .com and this resolved the issue


That’s great, I’m glad you got it sorted! :partying_face:

1 Like

Hi @iainsproat when the load balancer is behind an Application Gateway we’ve configured this to take the value of a private address for AKS which is but we still get failed to fetch error for the 1st registered user. Is there an issue with using *.io ?

It should be agnostic to the tld, so the .io tld is unlikely to be the issue.

Could you share the exact wording, or screenshot, of the fetch error? I assume it is thrown by the frontend?

My suspicions are it is due to the tls certificates having an invalid hostname or perhaps CORS, but we may be able to determine from the error message.

Hi Ian, it is the frontend, there isn’t much in the frontend screen shot please see attached. I couldn’t see the anything in the frontend logs or server logs to provide more detail

ah, sorry - I should have been more explicit. I meant a screenshot of the output in the console of your browser’s developer tools.

Report with same issue here.

Detail :

In @chuongmep’s case, I believe this is due to the frontend being requested via http. The frontend makes a request to the backend via https. Unfortunately the certificate for https was not correctly generated, and this likely resulted in the net::ERR_CONNECTION_REFUSED message we see in the console of the frontend. See for a possible solution for this issue in @chuongmep’s environment (Docker Compose deployed to a DigitalOcean Droplet).

It’s likely that the problem @shiangoli reported has similar roots, but without the error message from the console it is not possible to say for sure.

1 Like

My problem resolved by fill email to get certificate, cheer :heart_eyes:


Hi @iainsproat, please see attached it appears to expect https to be used. We have configured SSL termination at the gateway and the backend non SSL. I would prefer if we were able to use SSL passthrough but struggled see the following

post Application Gateway fronting Speckle on Kubernetes - #3 by shiangoli

Thanks @shiangoli - it looks like the frontend is attempting to connect to nginx directly (via http), bypassing your domain gateway. Your browser will then flag the mixed https and http as insecure content and block the http call.

To help with my understanding of your configuration, can you confirm the values of domain and ssl_canonical_url in your helm chart values?

Hi @iainsproat the domain is set to the private url not the url in the public DNS and ssl_canonical_url is set to false

ssl_canonical_url: false

Have you tried setting the domain value to that of your public url? What was the error/outcome with that configuration?

Hi @iainsproat we tried this before and just tried this again now and couldn’t get this to work 502 bad gateway error. It would be nice to know what would be the right configuration for fronting the service using application gateway and the different options SSL termination or pass through?

Thanks for trying that combination. Was the 502 error being generated by nginx or your gateway? What did the nginx logs show?

A gateway with separate domain and TLS termination is not something we’ve had to support before so hasn’t been tested. I’m not sure what would work, if anything.

There are a number of combinations here that you could work through to determine if any are possible. Which combinations have you already tried, and what were the outcomes?

  1. SSL
    • passthrough
    • termination at gateway, http to speckle-server nginx
    • termination at gateway, with onward request using tls with self-signed certificates to speckle-server nginx (tls certificate is added to nginx)
  2. domain value in helm chart
    • gateway url
    • nginx url
  3. ssl_canonical_url value in helm chart
    • false (I think this only makes sense with termination at gateway)
    • true
1 Like

Hi @iainsproat we’ve been experimenting with the various options

In the previous post we proved that “termination at gateway, http to speckle-server nginx” didn’t work. We subsequently tried the self signed certificate (3rd option above) on the back end we implemented akv2k8s on AKS to synchronise certificates from the KV which is a nice way to sync certificates. In the ingress-nginx and speckle namespaces you have the following

NAME                                          VAULT                VAULT OBJECT                          SECRET NAME   SYNCHED   AGE   my-kv-dev-uksouth   nginx-privatelink-uksouth-azmk8s-io   server-tls    7s        6h

and when you describe the above you get the following

  Type    Reason  Age                      From                     Message
  ----    ------  ----                     ----                     -------
  Normal  Synced  2m45s (x413 over 3h28m)  azurekeyvaultcontroller  AzureKeyVaultSecret synced to Kubernetes Secret successfully with change from Azure Key Vault

When we browse via the gateway we still get 501 error and backend health status as follows

The Intermediate certificate is missing from the backend server chain. Please ensure that the certificate chain is complete and correctly ordered on the backend server.

Looking for possible backend issues I noticed this on the frontend-2 pod logs with a failed reason: self signed certificate

Apollo Client error {
  operation: {
    variables: {},
    extensions: {},
    operationName: 'ActiveUserMainMetadata',
    query: { kind: 'Document', definitions: [Array] }
  networkError: FetchError: request to https://nginxprivateurl/graphql failed, reason: self signed certificate
      at ClientRequest.<anonymous> (file:///speckle-server/server/node_modules/node-fetch-native/dist/shared/node-fetch-native.2b047dc1.mjs:6371:11)
      at ClientRequest.emit (node:events:525:35)
      at TLSSocket.socketErrorListener (node:_http_client:494:9)
      at TLSSocket.emit (node:events:513:28)
      at emitErrorNT (node:internal/streams/destroy:157:8)
      at emitErrorCloseNT (node:internal/streams/destroy:122:3)
      at processTicksAndRejections (node:internal/process/task_queues:83:21) {
    type: 'system',
    erroredSysCall: undefined
  graphQLErrors: undefined,
  forward: [Function (anonymous)]

I’m wondering if the above has proved Speckle does not work with self signed certificates? Please let me know if this is true? If so the only other option available to us is the 1st option SSL Pass Thru (Digicert cert for the public and private urls)

This sounds like a positive step forward, and glad you have a clearer picture as to what will work.

From this error message it seems we also need to add the CA Certificate to Frontend 2 so that the requests it makes can validate the self-signed certificate that is being run.

We will have to amend Frontend 2 pod to support the NODE_EXTRA_CA_CERTS environment variable, and allow the certificate to be mounted into it.

In the meantime, Node will trust a Digicert signed certificate so that may also be an option for you.

Hi @iainsproat,
We have implemented the 3rd scenario https and termination at the gateway then issuing another https request to the ingress-nginx load balancer. We also created a certificate with sub domains hence the public facing is the parent and the child domains sits in the private network. From a certificate stand point we have got this resolved and have experimented with other backend test applications to prove this.
When on a debug probe I can run a curl on the private dns direct to the ingress-nginx load balancer using https and the page loads successfully however when we try to run this from the frontend we get the initial registration screen but on registration we get failed to fetch error. Please see below. The error is it cannot resolve the private DNS which was expected. The helm values file holds the private DNS and if we change this to the public domain then it would appear to have a problem with the certificate, the error
The Common Name of the leaf certificate presented by the backend server does not match the Probe or Backend Setting hostname of the application gateway. Stuck atm it would appear fronting it with a gateway is not supported?

1 Like

Thank you for the feedback @shiangoli.

As mentioned above, a gateway with separate domain and TLS termination is not something we’ve had to support before so hasn’t been tested.

We think this is due to the response sent by the server. If you attempt to sign in, the server responds with a redirect url for successful sign-ins. This url is based on the Canonical URL, which in your case (I assume) is the internal URL. Unfortunately this will be sent to your browser which cannot successfully resolve the Internal URL.

It appears that because the Canonical URL is used for a number of purposes, setting a value which satisfies one purpose causes it to fail others. We don’t currently have the spare capacity to look into this right now, though the path to resolving this if you wished to investigate would be to consider all the places that Canonical URL is being used and allow it to be more finely configured - perhaps passing in a different variable.