Cannot delete role menber: PublicAccessAuthenticationToken: Confidential transport (HTTPS)

[jerryMlewis]

Hi,

I have a new EJBCA CE instance built using Docker (the easiest approach).
I got the SuperAdmin cert generated and imported on my computer.

when I am about to delete PublicAccessAuthenticationToken: Confidential transport (HTTPS) role member, it threw an error:

Anyone came across with the same issue?
I cannot delete this role. Everyone can basically access the WebUI and as a PKI admin, I don't want that :(

[merryo11]

Can you try clearing your browser cache and then try otherwise you can disable it by going through advance option and deny all the accesses.

[jerryMlewis]

I even tried different browsers and use private/incognito mode - none worked.
So far, I tried the following:

• Created a new role "test" with access rule : Super Administrator and added PublicAccessAuthenticationToken: Confidential transport (HTTPS).
• In the "Super Administrator Role", I was able to remove PublicAccessAuthenticationToken: Confidential transport (HTTPS).
• Now, I went ahead and tried deleting the "test" role and got nothing. It says the same thing.
• I tried changing "test" access rule to something else other than Super Admin and got the same error.

Based from my observation, looks like ublicAccessAuthenticationToken: Confidential transport (HTTPS) needs to be a Super Admin and I can't remove it.

[primetomas]

I’m feeling that there was a question like this quite recently. I can’t find it now from the mobile. The easy, on top of my head answer, I think is to use the CLI EJBCA.sh roles to delete the unwanted role.
if you make the installation not with TLS setup simple you will get the superadmin p12 and the desired role setup from the beginning.

[jerryMlewis]

Hello Tomas,

I tried removing the role using cli. The role with it was removed but even the superadmin cert is specified, I couldn't get in to webui.
I spun up another vm just to isolate the issue and I got the same result using the current available version:

I used to spin up docker images since version 8.0 but this is the first time I'm having this issue.

[primetomas]

Did you start the container specifying
TLS_SETUP_ENABLED="true"

[grzleadams]

We saw this as well. I think this is the discussion you were referring to, @primetomas.

I still haven't figured out why I can't remove PublicAccessAuthenticationToken from SuperAdmin. As far as I can tell my ingress configuration is all correct.

[primetomas]

Did all of you start with TLS_SETUP_ENABLES="simple"?

I just tried this and in the TLS config if I do:
openssl s_client -connect localhost:443
it says (among other things)
"No client certificate CA names sent"

So client cert authentication with a certificate issued by the generated Management CA doesn't work.

I can remove the public transport role member by going SSHing into the container and using the CLI.

docker exec -ti 237f86fa9f6d /bin/bash
cd /opt/keyfactor/bin
./ejbca.sh roles removeadmin --role "Super Administrator Role" --value "" --caname "ManagementCA" --with PublicAccessAuthenticationToken:TRANSPORT_CONFIDENTIAL

But since client cert authentication doesn't work after this, I can't get into the system. I think the ManagementCA certificate must be added to the truststore and TLS in WildFly bounced.

[primetomas]

In that case, with an ingress, I think you should be fine.
Did you try to delete the role member with the CLI? (backup your database first so you can restore it)

[grzleadams]

Yeah, but like you saw, once I removed PublicAccessAuthenticationToken:TRANSPORT_CONFIDENTIAL and PublicAccessAuthenticationToken:TRANSPORT_ANY, I lost access.

[grzleadams]

I don't understand why later acts the same as simple if it still generates the ManagementCA; I would expect them to behave the same, only the reverse proxy forwards the certificate instead of it going directly to the backend. Per docs:

Production installation should use TLS_SETUP_ENABLED="true" when installing in order to require client certificate access to the Admin UI. With "true" the container will generate a ManagementCA that will be used to issue both server and initial client TLS certificate used for administration. The third option is TLS_SETUP_ENABLED="later" in which case it requires TLS configured on reverse proxy in front of EJBCA, and allows anyone access over TLS to begin using EJBCA.

[grzleadams]

For what it's worth, simply changing it to true while retaining the old database/ManagementCA doesn't seem to have helped. Neither did fully redeploying with TLS_SETUP_ENABLED: true.

[grzleadams]

As a test, I re-deployed again with TLS_SETUP_ENABLED="true", ingress disabled, proxyHTTP configured and enabled, and nginx enabled (as a LoadBalancer). Even with that configuration, I'm seeing the same behavior as with ingress, so this definitely seems to be something with WildFly and not ingress config.

[ghost]

I had the same problem. My configuration file looked like this: "
admin@Server:/docker/ejbca$ cat docker-compose.yaml
networks:
access-bridge:
driver: bridge
application-bridge:
driver: bridge
services:
ejbca-database:
container_name: ejbca-database
image: "library/mariadb:latest"
networks:
- application-bridge
environment:
- MYSQL_ROOT_PASSWORD=Q@wertyuiop
- MYSQL_DATABASE=ejbca
- MYSQL_USER=ejbca
- MYSQL_PASSWORD=ejbca
volumes:
- ./datadbir:/var/lib/mysql:rw
restart: unless-stopped
ejbca:
hostname: ejbca
container_name: ejbca
image: keyfactor/ejbca-ce:latest
depends_on:
- ejbca-database
networks:
- access-bridge
- application-bridge
environment:
DATABASE_JDBC_URL: jdbc:mariadb://ejbca-database:3306/ejbca?characterEncoding=UTF-8
LOG_LEVEL_APP: INFO
LOG_LEVEL_SERVER: INFO
TLS_SETUP_ENABLED: true
restart: unless-stopped
ports:
- "8081:8080"
- "8443:8443"
admin@Server:/docker/ejbca$
In my case, entering the database root password in the CLI worked: bash-5.1$ ./ejbca.sh roles removeadmin --role "Super Administrator Role" --value "" --caname "ManagementCA" --with PublicAccessAuthenticationToken:TRANSPORT_CONFIDENTIAL -u ejbca --clipassword='Q@wertyuiop'
2025-08-24 13:06:51,707+0000 INFO [org.ejbca.ui.cli.roles.RemoveAdminCommand] (main) Using 'TYPE_UNUSED' implied by 'TRANSPORT_CONFIDENTIAL'.
2025-08-24 13:06:51,766+0000 INFO [org.ejbca.ui.cli.roles.RemoveAdminCommand] (main) Removed role member: '-' TRANSPORT_CONFIDENTIAL TYPE_UNUSED '' from role 'Super Administrator Role'
bash-5.1$ exit
exit

[primetomas]

I managed to do this with the UI now. After starting with a public access and creating a new CA and a superadmin certificate. The superadmin need to be a role member in the superadmin role. After this I need to restart the container (using the same database). Then the CA certificate for superadmin role members are automatically added to the TLS trust store. Authenticating with the cert (probably need to restart the browser, or use another one) get me in as "Welcome SuperAdmin". And then I could click the button to remove public access.

The crux is really to not be authenticated with the public role, and you may need a container bounce for this.

In a clusters deployment you would mount in the truststore, to be the same one for all your cluster nodes so this is only an initial installation step.

[grzleadams]

I guess I'm curious about why the CA created by a non-simple scenario doesn't get added to the trust store in the same way (because then this would just work out of the box). Creating a SuperAdmin with a new CA when a SuperAdmin already exists with the automatically-generated CA doesn't seem like the right solution here.

[primetomas]

You don't need to create a new CA. What the above tries to say is that the CA certificate of members of the Superadmin role is added to the truststore automatically on container startup. If you have created a superadmin after first start (like TLS_SETUP=simple), you need to restart the container.
(That's a single-container use case. A K8s style usage is to have a pod with an ingress controller)

[grzleadams]

Gotcha. So is the issue we're seeing with the K8s (pod+ingress) case possibly the same cause as the single-container case (i.e., the generated CA is not added to the trust store)?

[primetomas]

Yeah, the (root) CA certificate must be added to the truststore so it appears in the "trusted CAs" part from the server in the TLS handshake with the client.

Looks like this for example with a "openssl s_client -connect localhost:8443"

Server certificate
-----BEGIN CERTIFICATE-----
MIIDnTCCAoWgAwIBAgIQAP8FVyg06cu5qNOpmLfhHzANBgkqhkiG9w0BAQsFADA1
MRYwFAYDVQQDDA1NYW5hZ2VtZW50IENBMQ4wDAYDVQQKDAVQSy1ETTELMAkGA1UE
BhMCQUUwHhcNMjQwODMwMDk1MTIxWhcNMjYwMzE0MTQzMTA3WjA4MRIwEAYDVQQD
DAlsb2NhbGhvc3QxFTATBgNVBAoMDEVKQkNBIFNhbXBsZTELMAkGA1UEBhMCU0Uw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwyicFQKIYvtlUunjnFo+Q
APAXbYuOs5y1+WTVc6sRxzTh9H7eONKyUH2eQEQxMJ3ADxOwSk645gU3fiBc/mUR
wLUWGvFjpWnGEwPGqbcOmIlNN3FDUU4/T2zeoMI3Zlr/EHWmBArOhLyUhrU4J3Am
DpfGjcNJYRluLOBGGWFg9DrZOXy+dtL4bYS1EKKIndLvVSw3fJf4OLOgU0PGKXaA
mkSkDrAiHnxcy0NDwMTRaz0tYfUCMtPketPIss3RAA6TG4ZfdzbsKWQzHusay6+M
BnUQ6+YSd7uWXCdmiDIo7kQvBSkxG+4Tb/Q1hLzAO8VlzgUwcZ2zGFRwvSh8qCOV
AgMBAAGjgaUwgaIwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBS7aJ9wWNYqtLjB
OGb6w8+PwZhq2jAtBgNVHREEJjAkhwR/AAABgglsb2NhbGhvc3SCEWVqYmNhLmV4
YW1wbGUuY29tMBMGA1UdJQQMMAoGCCsGAQUFBwMBMB0GA1UdDgQWBBQedFSJtP74
3WsZcGPsNZ+d7iy/PjAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEB
AE6xIAKc60T3eCgnznAQQ8NpxYHaNjpMqDsItQPO4JR8vvgmY69ZhmPFyewrGZXy
T9AkZz6M8s2GwMd9XDtV2TbxvlpRvHxvrFkx6OIMmfeVso8UJIvQ20/Lu2Cvw2xA
2yJhTM7FFN5+suk9T+JvpVzC175/ctjSYm4W1wQSWigALv3LemOzWJAATGwEN6o5
fOMplq/YnSsturh+VRk5GO224uySYZ5Wa+mdYPjV0kB7atLVRxlpERsNV+ccSyMu
aUGTGUFei6cZTp8GubmWt7z8W0xmTuD2UROn96VKfgWxyMq+LGOBfn1U8RRpG65B
fc/2FstcNAUmZPVTTeoEY/0=
-----END CERTIFICATE-----
subject=CN = localhost, O = EJBCA Sample, C = SE
issuer=CN = Management CA, O = PK-DM, C = SE
---
Acceptable client certificate CA names
CN = Management CA, O = PK-DM, C = SE
Requested Signature Algorithms: Ed25519:Ed448:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:0x1A+0x08:0x1B+0x08:0x1C+0x08:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA1:RSA+SHA1
Shared Requested Signature Algorithms: Ed25519:Ed448:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512

[grzleadams]

Sure, and my EJBCA instance does do that (the ManagementCA-Alternate is a CA I created to try and work around this):

Acceptable client certificate CA names                                                                
CN = ManagementCA, O = EJBCA Sample, C = SE
CN = ManagementCA-Alternate                             

But when I authenticate with either of those certs I just get Welcome to EJBCA Administration. and can't remove public access. So it seems like the certificate I'm authenticating with is not actually being passed even though my ingress looks right:

- apiVersion: networking.k8s.io/v1                                                                                                                                                                          
  kind: Ingress                                                                                                                                                                                             
  metadata:                                                                                                                                                                                                 
    annotations:
      meta.helm.sh/release-name: ejbca
      meta.helm.sh/release-namespace: ejbca
      nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
      nginx.ingress.kubernetes.io/auth-tls-secret: ejbca/managementca-secret
      nginx.ingress.kubernetes.io/auth-tls-verify-client: optional_no_ca
      nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
      nginx.ingress.kubernetes.io/backend-protocol: HTTP
      nginx.ingress.kubernetes.io/configuration-snippet: |
        proxy_set_header SSL_CLIENT_CERT $ssl_client_cert;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      nginx.ingress.kubernetes.io/proxy-body-size: "0"
      nginx.ingress.kubernetes.io/proxy-set-headers: ejbca/custom-headers
      nginx.ingress.kubernetes.io/ssl-redirect: "false"

So if the server expects one of those two certificates to authenticate as SuperAdmin, and I'm passing one of them, and ingress is passing the certificate to the upstream... does this mean it's a WildFly thing?

[grzleadams]

Just for the sake of completeness, this is what's in ejbca/custom-headers. It shouldn't be required but I saw some older issues where adding it helped.

apiVersion: v1
data:
  X-SSL-CERT: $ssl_client_escaped_cert
immutable: false
kind: ConfigMap
metadata:
  name: custom-headers
  namespace: ejbca