NPM Plus sometimes gives wildcard dummy certificate instead of cerbot's

[TechKnowCase]

Hi,

I tried to troubleshoot this on my side, but I can't seem to see the logic in this.

Issue: When visiting one of my reverse proxied websites, I sometimes get a dummy certificate (wildcard, expires in 3025).

my setup:

Had NPM Plus docker switched to docker compose ( tried to see if this was the issue)copied the template from your github. I have multiple websites using the same domain: ombi.example.com; emby.example.com; bitwarden.example.com etc. I use one certificate (cloudflare API key) that has both example.com and *.example.com domain name. Some website seems to always work, some works from time to time but when they do work, if I ctrl+shift+r to completely refresh the page, I get the error back. I disabled in my browser HSTS as a troubleshooting step. If I click "proceed to XYZ", I get the same security error back and never get to see the website.

docker compose: (with removed commented out options, only major modification to the template is the network, since I wanted to keep unraid's webgui on 443 and 80; no email address is correct for cerbot using cloudflare API?)

services:
  npmplus:
    container_name: npmplus
    image: docker.io/zoeyvid/npmplus:latest # or ghcr.io/zoeyvid/npmplus:latest
    restart: unless-stopped
    networks:
      br0-73:
      # You can optionally specify a static IP here
           ipv4_address: 10.10.73.4 # Choose an available IP in your range
#    network_mode: bridge
#    ipc: host # required when you want to use the openappsec attachment module
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
      - SETGID
      - SETUID # required if you change PUID/PGID or you enable the inbuilt php-fpm
      - CHOWN # required if you change PUID/PGID
      - FOWNER # required if you change PUID/PGID
      - DAC_OVERRIDE # required if you change PUID/PGID
    security_opt:
      - no-new-privileges:true
    volumes:
      - "/mnt/cache/appdata/npmplus2/data:/data"
      - "/mnt/cache/appdata/npmplus2/var/www:/var/www" 
    environment:
      - "TZ=America/Montreal" # set timezone, required, set it to one of the values from the "TZ identifier" https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List
#      - "ACME_EMAIL=your-email" # email address to use for acme, optional for letsencrypt, but required for zerossl and google public ca
      - "PUID=99" # set user id, needs to be a number greater or equal to 99, or equal to 0, default 0 (root), if network mode host is used and PUID changed, you may need to set sysctl net.ipv4.ip_unprivileged_port_start=0 to bind ports like 80 or 443, please note that this will allow all non-root services to bind ports below 1024
      - "PGID=100" # set group id, needs to be a number greater or equal to 99, or equal to 0, default 0 (root), requires non-zero PUID

# This can be used to enable crowdsec, see README for a guide
  crowdsec:
    container_name: crowdsec
    image: docker.io/crowdsecurity/crowdsec:latest
    restart: unless-stopped
#    network_mode: bridge
    networks:
      br0-73:
      # You can optionally specify a static IP here
           ipv4_address: 10.10.73.13  # Choose an available IP in your range
    ports:
      - "127.0.0.1:7422:7422"
      - "127.0.0.1:8080:8080"
    environment:
      - "TZ=America/Montreal" # needs to be changed
      - "USE_WAL=true"
      - "COLLECTIONS=ZoeyVid/npmplus"
    volumes:
      - "/mnt/cache/appdata/npmplus2/crowdsec/conf:/etc/crowdsec"
      - "/mnt/cache/appdata/npmplus2/crowdsec/data:/var/lib/crowdsec/data"
      - "/mnt/cache/appdata/npmplus2/npmplus/nginx/logs:/opt/npmplus/nginx/logs:ro"
      - "/mnt/cache/appdata/npmplus2/openappsec/logs:/opt/openappsec/logs:ro" # only uncomment if you also use the openappsec-agent container

networks:
  br0-73:
    external: true
    name: br0.73

volumes:
  shm-volume:
   driver: local
   driver_opts:
     type: tmpfs
     device: tmpfs

example of bitwarden configuration (one I have almost always issues with; Crowdsec was disabled as a troubleshooting step):

One important detail, I have my UDM Pro set to forward DNS to the domain *.example.com to NPM Plus's IP. Outside of my network, I can reach the websites with no issue (though cloudflare proxy).

I usually have no errors in the docker's log, but this time I got this:

[Access        ] › ✖  error     proxy_hosts:list undefined Permission Denied

I'm not too sure what files are being denied their permissions:

I re-set the correct permissions in unraid (chown -R nobody:users), redeployed the container.

When I disable the DNS "rule" in unifi and disable cloudflare proxy, I can also successfully reach bitwarden. I can verify with an addon in the browser that DNS resolves to my WAN IP, not cloudflare or NPM's local ip.

[Zoey2936]

so the issue only appears when using local dns rewrites?

[Zoey2936]

do you maybe have DoH enable din firefox which ignores your dns overwrites?

[TechKnowCase]

No, it doesn't seem to use it:

If the addon is to be trusted:

Could this is because of IPV6? This is not my ip but cloudflare's

[TechKnowCase]

I'm afraid to say, it seems to have fixed itself by setting ipv6 as well. I set a DNS rewrite for ipv6 and set my ipv6 address in cloudflare and it seems to have fixed the issue. I'm not sure if I could put this info somewhere in the configuration as to warn other users if they come across this issue too.

It worked for a while, but after re-enabling cloudflare's proxy on both A & AAAA records, it came back:

Disabled cloudflare proxy again and waited a few minutes:

example.com and bitwarden.example.com are both not proxied anymore, while at the same time paperless.example.com is:

As for chrome/chomium/ungoogled chomium, they all refuse to use local DNS. For bitwarden and example.com, they use my IPv4 and get the cerbot certificate. For paperless, it gets cloudflare's ip with, for some odd reason, the same certificate generated in npm plus: the same SHA-256 certificate fingerprint, public key, same lifetime, etc.

[Zoey2936]

what does the dns page in chrome://net-internals/#dns resolve your domain to?

[aredspy]

Also started happening to me as well, haven't looked too deep into it yet, but I keep my public facing subdomains on a separate port with forwarding from my router like this:

listen 0.0.0.0:5443 ssl;                                                                                                             
listen [::]:5443 ssl;

listen 0.0.0.0:5443 quic;                                                                                                            
listen [::]:5443 quic;                                                                                                               

Works perfectly fine from cloudflare with proxy on and off, but local connections get the dummy cert.

Also using Bitwarden lol.

Weirdly enough, it starts working fine when I access an internal subdomain at the same time, which is running default on 443.

My blind guess is that it might be some nginx ordering jank, since putting in the custom config from npm puts it at the bottom of the conf file, but I'm pretty sure that shouldn't matter for defining a listener.

Not sure if you have the same setup or if this is a deeper issue somewhere else.

[LiamillionSS]

Also seeing this with porkbun dns certificate, the cert worked fine in zoraxy but I had to switch to npm due to the headscale and matrix header issues.

Both firefox and chromium show the same certificate issue, and curl -v shows the following:

• Server certificate:
• subject: CN=*
• start date: May 13 22:33:22 2026 GMT
• expire date: Sep 13 22:33:22 3025 GMT
• issuer: CN=*
• Certificate level 0: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA512
• SSL: certificate subject name '*' does not match target hostname 'scale.<>.<>'
• closing connection #0
  curl: (60) SSL: certificate subject name '*' does not match target hostname 'scale.<>.<>'

[LiamillionSS]

For anyone else with custom/advanced nginx configuration parameters, check to make sure they are done correctly before posting about something not working to limit the chance of publicly outing one's skill issues.