ShinyProxy Operator with internal domain and custom certs

ShinyProxy
1

How would I be able to enable SPO to use SSL/TLS

I tried to disable CADDY ACME and add the certs to ShinyProxy, but that did not work.

environment:
SPO_ORCHESTRATOR: docker
SPO_DOCKER_GID: 995
SPO_CADDY_ENABLE_TLS: “true”
SPO_CADDY_ACME: “false”

https:
enabled: true
certificate-file: /opt/shinyproxy-docker-operator/input/shinyproxy.bdx.com.crt
certificate-key-file: /opt/shinyproxy-docker-operator/input/shinyproxy.bdx.com.key

2

Hi

It seems you are using some configuration options that do not exists.
You can find the correct configuration for custom TLS certs here: Docker | ShinyProxy

It could also be useful to have a look at the structure of the input directory: Docker | ShinyProxy

So your configuration becomes:

SPO_ORCHESTRATOR: docker
SPO_DOCKER_GID: 995
SPO_CADDY_ENABLE_TLS: "true"

proxy:
 realm-id: my-realm
 # ..
# make sure to not indent these options, these should sit at the highest level in the config file
caddyTlsCertFile: /opt/shinyproxy-docker-operator/input/shinyproxy.bdx.com.crt
caddyTlsKeyFile: /opt/shinyproxy-docker-operator/input/shinyproxy.bdx.com.key
3

Thanks for the reply.
I tried the approach from Using custom certificates
The issue is that the domain bdx.com can’t be resolved because it is private.
GPT 5.4 was giving all sorts of bad ideas.

The simple question is if I have my own key and crt how can I use them and not have CADDY try to resolve the host or use Let’s Encrypt?

This is what sudo docker logs -f sp-caddy is showing

{“level”:“error”,“ts”:1775658569.9199247,“logger”:“http.acme_client”,“msg”:“validating authorization”,“identifier”:“shinyproxy.bdx.com”,“problem”:{“type”:“urn:ietf:params:acme:error:dns”,“title”:“”,“detail”:“DNS problem: NXDOMAIN looking up A for shinyproxy.bdx.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for shinyproxy.bdx.com - check that a DNS record exists for this domain”,“instance”:“”,“subproblems”:},“order”:“https://acme-staging-v02.api.letsencrypt.org/acme/order/281211673/35805832883",“attempt”:1,"max_attempts”:3}

4

If you specify the caddyTlsCertFile and caddyTlsKeyFile options, the operator use these certs and will no try to use let’s encrypt.

If it still doesn’t work, could you share your full configuration file?

5

localhost.shinyproxy.yaml

spring:
session:
store-type: redis
proxy:
store-mode: Redis
docker:
internal-networking: true
stop-proxies-on-shutdown: false
authentication: simple
realm-id: localhost
caddyTlsCertFile: /opt/shinyproxy-docker-operator/input/shinyproxy.bdx.com.crt
caddyTlsKeyFile: /opt/shinyproxy-docker-operator/input/shinyproxy.bdx.com.key
users:

  • name: jack
    password: password
    groups: scientists
  • name: jeff
    password: password
    groups: mathematicians
    specs:
  • id: 01_hello
    display-name: Hello Application
    description: Application which demonstrates the basics of a Shiny app
    container-cmd: [ “R”, “-e”, “shinyproxy::run_01_hello()” ]
    container-image: openanalytics/shinyproxy-demo
    access-groups: [ scientists, mathematicians ]
  • id: 06_tabsets
    container-cmd: [ “R”, “-e”, “shinyproxy::run_06_tabsets()” ]
    container-image: openanalytics/shinyproxy-demo
    access-groups: scientists
    image: openanalytics/shinyproxy:3.2.3
    fqdn: shinyproxy.bdx.com
    server:
    forward-headers-strategy: native

docker-compose.yml

services:
shinyproxy-operator:
image: openanalytics/shinyproxy-operator:2.3.1
environment:
SPO_ORCHESTRATOR: docker
SPO_DOCKER_GID: 995
SPO_CADDY_ENABLE_TLS: “true”
volumes:

  • ./input:/opt/shinyproxy-docker-operator/input
  • /var/run/docker.sock:/var/run/docker.sock:ro
  • /opt/shinyproxy-docker-operator/data:/opt/shinyproxy-docker-operator/data
    group_add:
  • 995 # replace by the id of step 6
    networks:
  • sp-shared-network
    restart: always
    labels:
    app: shinyproxy-operator
    user: “1001”
    networks:
    sp-shared-network:
    name: sp-shared-network

Thanks for looking. It works without TLS and I know the certs are good.

6

Hi, the caddyTlsCertFile are top-level configuration options, so they should be put outside the proxy configuration block (see my example in my previous post).

Your configuration becomes:

spring:
  session:
    store-type: redis
proxy:
  store-mode: Redis
  docker:
    internal-networking: true
  stop-proxies-on-shutdown: false
  authentication: simple
  realm-id: localhost
  users:
    - name: jack
      password: password
      groups: scientists
    - name: jeff
      password: password
      groups: mathematicians
  specs:
    - id: 01_hello
      display-name: Hello Application
      description: Application which demonstrates the basics of a Shiny app
      container-cmd: [ “R”, “-e”, “shinyproxy::run_01_hello()” ]
      container-image: openanalytics/shinyproxy-demo
      access-groups: [ scientists, mathematicians ]
    - id: 06_tabsets
      container-cmd: [ “R”, “-e”, “shinyproxy::run_06_tabsets()” ]
      container-image: openanalytics/shinyproxy-demo
      access-groups: scientists

image: openanalytics/shinyproxy:3.2.3
fqdn: shinyproxy.bdx.com
server:
  forward-headers-strategy: native

caddyTlsCertFile: /opt/shinyproxy-docker-operator/input/shinyproxy.bdx.com.crt
caddyTlsKeyFile: /opt/shinyproxy-docker-operator/input/shinyproxy.bdx.com.key

I’ll make the documentation on this setting a bit more clear.

1 Like