Intended reverse proxy setup with docker?

[takakv]

I've been experimenting with EJBCA since I want to conveniently manage a PKI to use for labs with my students.

I am currently using a setup based on Docker compose which I pieced together from the official docs and various discussions here. However, the approach I've derived from these seems quite strange, and I was wondering if there is a better, intended way to do it.

1. If I understand correctly, when using the official CE docker container, the management CA cannot be manually configured. I have thus generated a ManagementCA and issued a SuperAdmin certificate from it with OpenSSL.

2. I am running the Docker container with TLS_SETUP_ENABLED=later and PROXY_HTTP_BIND=0.0.0.0 for the reverse proxy.

3. I've set up the following reverse proxy with NGINX, which requires a ManagementCA-issued certificate to access the EJBCA admin panel.

   server {
       listen 443 ssl;
       server_name pki.local;
       server_tokens off;
   
       include tls.conf # ciphersuites and TLS versions
   
       ssl_certificate     /etc/ssl/certs/ca-server.pem;
       ssl_certificate_key /etc/ssl/private/ca-server-key.pem;
   
       ssl_verify_client optional_no_ca;
       
       location / {
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
           proxy_set_header SSL_CLIENT_CERT $ssl_client_cert;
   
           proxy_pass http://ejbca-node1:8082$request_uri;
       }
   }
   

   I also have a separate configuration block for ocsp.pki.local which proxies HTTP requests to the internal responder url on port 8081. I omitted it here for brevity.

   Inspired from:

   • Setting up an nginx as a Proxy for EJBCA CE #745
   • How to use client certificates for admin ui authentication #397
   • API on Docker container not working through proxy #614 (which contains more linked discussions)
   • https://docs.keyfactor.com/ejbca/9.0/setting-up-an-apache-web-server-as-a-proxy
   • https://github.com/Keyfactor/ejbca-community-helm/blob/main/templates/nginx-configmap.yaml

   As I understand, port 8082 is used for https traffic, and therefore needed for the client certificate verification, and 8081 is used for http traffic.

4. I tell EJBCA about my ManagementCA, and remove the one initialised by default.
   a. Disable SuperAdmin public access

   docker exec -it ejbca ejbca.sh roles removeadmin \
       --role "Super Administrator Role" \
       --caname "" \
       --with PublicAccessAuthenticationToken:TRANSPORT_ANY  \
       --value ""
   

   b. Restrict SuperAdmin access to the certificate holder

   docker cp openssl/managementCA.pem ejbca:/tmp/ca.pem
   docker exec -it ejbca ejbca.sh ca importcacert \
       --caname "ManagementCA" -f "/tmp/ca.pem" \
       -initauthorization -superadmincn SuperAdmin
   

   c. Delete the public access role (deleting it before restricting superadmin access bricks the installation for some reason)

   docker exec -it ejbca ejbca.sh roles removerole \
       --role "Public Access Role"
   

Is there a more elegant way for the custom managementCA setup in step 4 that I have missed?

Additionally, is the Docker container inteded at all for production set-ups, or is the inteded setup such, that users create their own EJBCA container with install-time configurations, and the official container solely for testing?

Thank you in advance for any suggestions.

---

Some observations about TLS_SETUP_ENABLED=true vs TLS_SETUP_ENABLED=later.

It is my understanding from the documentation that by setting TLS_SETUP_ENABLED to true, I will need HTTPS between the proxy and EJBCA as well, which is undesirable (to me). However, client certificate authentication would then be required by EJBCA also for the initial access, which would prevent the potential issue with TLS_SETUP_ENABLED=later of having an insecure inital deployment. Currently I see two ways to avoid this:

• Require the proxy to verify the client certificate as well, e.g.

ssl_verify_client       optional;
ssl_client_certificate  /etc/ssl/certs/managementCA.pem;
ssl_verify_depth        1;

location / {
   # Do not check for the client certificate verification for everything since there are locations
   # that might benefit from HTTPS without needing client auth (e.g. parts of the RA web).
   ...
}

location /ejbca/adminweb {
    # Adminweb must ONLY be accessible to users with valid certificates.
    # NGINX does not allow setting 'ssl_verify_client' per location
    # in the same server block.
    if ($ssl_client_verify != "SUCCESS") {
        return 496;
    }

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header SSL_CLIENT_CERT $ssl_client_cert;

    proxy_pass http://ejbca-node1:8082$request_uri;
 }

• Ensure that step 4 is executed automatically immediately after deployment, e.g. with Ansible. Then the admin panel does not remain accessible without a valid client certificate. In this case TRANSPORT_CONFIDENTIAL is used instead of TRANSPORT_ANY.

Interestingly enough, client certificate auth is not required even with TLS_SETUP_ENABLED=true : without the reverse proxy client certificate requirement, the admin panel can be accessed over HTTPS while providing no certificate, and the admin panel asks the user to import or create a management CA as for TLS_SETUP_ENABLED=later.

It would seem that this happens when PROXY_HTTP_BIND is set (#420). If this is intended behaviour, then is there any meaningful difference between true and later? In both cases the initial deployment seems insecure to me without the proposed two workarounds. If not, then it seems to be undocumented behaviour, or perhaps even a bug.

[primetomas]

Hi, in general your setup looks fine. Did you look at the helm charts and deployment examples we provided? (a new release of EJBCA is expected soon btw).
There are a bunch of recent threads discussing docker-compose and different variants of ingress and proxy setups.

For the last question, yes the official docker container is considered production ready. Although some parts like versions, instant security updates and such, lag behind EJBCA Enterprise the base container is the same as used in large scale enterprise deployments.

[takakv]

Thank you very much for your answers!
Yes, I also looked at the helm charts (in the now archived repository) and deployment examples, but the plurality of the examples (which is certainly a good thing) confused me in trying to determine the ‘best practice’. I shall certainly review the more recent discussions.

[primetomas]

Yeah, the plurality of ways to do things certainly complicates things in the k8s ecosystem. I think there are several best practices, and the way we do production setups have changed over time as the ecosystem changes...For example @dobicinaitis is much more knowledgeable on these than I am.