[SOLVED] Almost identical Azure Docker containers, one works, one doesn't

Almost identical Azure Docker containers, one works, one doesn't

I have deployed two almost identical Azure Docker containers. The only differences are that one is configured for a virtual network, and the other is configured for public access. I try to curl both from the terminal on an Azure web app which is also on the virtual network (different subnet), the public instance works, the private instance gets a 404 error.

Here's the yaml for the internal instance:

additional_properties: {}
apiVersion: '2023-05-01'
extended_location: null
identity:
  type: SystemAssigned
location: australiaeast
name: myprivatecontainergroup
properties:
  containers:
  - name: myprivatecontainer
    properties:
      environmentVariables:
      - name: MODSEC_RULE_ENGINE
        value: 'DetectionOnly'
      - name: LOGLEVEL
        value: 'info'
      - name: SERVER_NAME
        value: private.example.com
      - name: PROXY_SSL
        value: 'on'
      - name: PROXY
        value: '1'
      - name: BACKEND
        value: https://mysamebackend.com
      image: owasp/modsecurity-crs:latest
      ports:
      - port: 443
        protocol: TCP
      resources:
        requests:
          cpu: 1.0
          memoryInGB: 1.5
      volumeMounts:
      - mountPath: /etc/nginx/conf
        name: myshare1
      - mountPath: /var/log/nginx
        name: logs
  initContainers: []
  ipAddress:
    autoGeneratedDomainNameLabelScope: Unsecure
    ports:
    - port: 443
      protocol: TCP
    type: Private
  isCustomProvisioningTimeout: false
  osType: Linux
  restartPolicy: OnFailure
  subnetIds:
   - id: /subscriptions/mysubscription/resourceGroups/myrg/providers/Microsoft.Network/virtualNetworks/amy-vn/subnets/mystorage
     name: mystorage
  sku: Standard
  volumes:
  - name: myvol1
    azureFile:
      sharename: myshare1
      storageAccountName: myaccount
      storageAccountKey: <key>
  - name: myvol2
    azureFile:
      sharename: myshare2
      storageAccountName: myacount
      storageAccountKey: <key>
tags: {}
type: Microsoft.ContainerInstance/containerGroups

And here's the public instance:

additional_properties: {}
apiVersion: '2023-05-01'
extended_location: null
identity:
  type: SystemAssigned
location: australiaeast
name: mypubliccontainergroup
properties:
  containers:
  - name: mypubliccontainer
    properties:
      environmentVariables:
      - name: MODSEC_RULE_ENGINE
        value: 'DetectionOnly'
      - name: SERVER_NAME
        value: public.example.com
      - name: PROXY_SSL
        value: 'on'
      - name: PROXY
        value: '1'
      - name: BACKEND
        value: https://mysamebackend.com
      image: owasp/modsecurity-crs:latest
      ports:
      - port: 443
        protocol: TCP
      resources:
        requests:
          cpu: 1.0
          memoryInGB: 1.5
      volumeMounts:
      - mountPath: /etc/nginx/conf
        name: myshare1
      - mountPath: /var/log/nginx
        name: logs
  initContainers: []
  ipAddress:
    autoGeneratedDomainNameLabelScope: Unsecure
    dnsNameLabel: mydnslabel
    fqdn: my.public.azurecontainer.io
    ports:
    - port: 443
      protocol: TCP
    type: Public
  isCustomProvisioningTimeout: false
  osType: Linux
  restartPolicy: OnFailure
  sku: Standard
  volumes:
  - name: myvol1
    azureFile:
      sharename: myshare1
      storageAccountName: myaccount
      storageAccountKey: mykey
  - name: myvol2
    azureFile:
      sharename: myshare2
      storageAccountName: myaccount
      storageAccountKey: mykey
tags: {}
type: Microsoft.ContainerInstance/containerGroups

I run the following curl commands on the same terminal in the virtual network:

When I run curl https://public.example.com it returns the page

When I run curl https://private.example.com it returns 404 error

The logs in the private container are showing the 404 error so I know it's connecting.

For testing purposes, I set the downstream server to public access, so it shouldn't be a firewall issue. I've run curl from the internal container and have verified that it can see the downstream server.

Any ideas on why they would be behaving differently?

I had Microsoft support look into it and they advised that because all connectivity is successful, the problem must lie within the configuration of the container.

Solution

I've worked this one out. It was actually an SSL certificate issue. Even though both containers were ultimately going to the same upstream server (samebackend.com), it was being masked by the container server names (public.example.com and private.example.com). Only public.example.com had an SSL certificate on samebackend.com. I added the certificate for private.example.com and it worked.