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
   • [BUG] API on Docker container not working properly #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.