Rest API access other than through localhost

[dug-ianc]

I'm using ejbca-ce inside a docker container. I've enabled all the services possible under the system configuration - protocols page and I seem to be able to access the rest API endpoints if I exec into the container and access it via localhost it works: For example

curl -s https://localhost:8443/ejbca/ejbca-rest-api/v1/certificate/status
However when I access it externally via the hostname, in a web browser like this:

https://myhostname.mydomainname:8443/ejbca/ejbca-rest-api/v1/certificate/status

It just returns "This service has been disabled." I am authenticated using an x509 cert. How do I enable external access as it doesn't appear to be obvious from the documenation? Thanks

[dug-ianc]

Replying to myself but perhaps Mandating a custom header for the API call is mandatory for "external" access

[primetomas]

This is used extensively. Are you sure your DNS name directs to the right host?
The same curl commands would work externally, REST API is an external API, should never be used inside the container. You need authentication however, using client certifciate.
What exactly is the curl command you use?

[dug-ianc]

The DNS name must be correct because I can access the admin interface and the RA through it. I've attached what I see "externally". Doing the same thing inside the docker container with cuirl, replacing the hostname with localhost returns a result though, so I'm not sure why. Is there a log somewhere that might tell me? Also, I'm using a cert in my browser when access it, which has SuperAdmin privs.

[primetomas]

I added mycahostname to my /etc/hosts file.

I started container with:
docker pull keyfactor/ejbca-ce
docker run -it --rm -p 80:8080 -p 443:8443 -h mycahostname -e TLS_SETUP_ENABLED="true" keyfactor/ejbca-ce
got my SuperAdmin.p12 from RA web, according to the console instructions.

Went into admin web:
https://mycahostname/ejbca/adminweb/

Enabled "REST Certificate management" in System Configuration->Protocol Configuration"

Ran the following curl command:
curl -k -X 'GET' 'https://mycahostname/ejbca/ejbca-rest-api/v1/certificate/status' -H 'accept: application/json'
{"status":"OK","version":"1.0","revision":"EJBCA 8.2.0.1 Community (39b6c93)"}

All looks good.

[dug-ianc]

On the host running the container, I checked /etc/hosts and noticed that cloud init had assigned it 127.0.0.1 so consequently that was also in /etc/hosts on the container. I have updated /etc/hosts with the IP address (which always existed in DNS) however I am still seeing the same issue. Is this because it would have already embedded '127.0.0.1' in some configuration file?

[dug-ianc]

This is what I'm seeing in the logs

2024-05-27 01:07:07,026+0000 INFO [org.ejbca.ui.web.rest.api.config.RestLoggingFilter] (default task-1) GET https://myca.mydomain:8443/ejbca/ejbca-rest-api/v2/certificate/status received from 10.0.2.100 X-Forwarded-For: null
2024-05-27 01:07:07,027+0000 ERROR [org.ejbca.util.ServiceControlFilter] (default task-1) Custom header for browser calls is absent with forbidden header: HttpServletRequestImpl [ GET /ejbca/ejbca-rest-api/v2/certificate/status ]

[dug-ianc]

Curl seems to work now at least, although the browser doesn't but I'm guessing that the custom header is "required" for browsers but not things like curl so that might be the reason

[primetomas]

I mentioned this, which is in System Configuration. But bo, typically you do not use a web browser to call a REST API, you typically want to prevent this in fact.

[dug-ianc]

Yes, I agree. I'd just made the assumption that there wouldn't be different behaviour and that it was entirely closed to anything outside of localhost, but I also updating the /etc/hosts file made a difference too, so thanks for point me in the right direction.

[martincorr]

I hit the same issue. The answer was to add a hosts entry for the hostname youre using from other machines. So if you are resting to https:/my-ejbca.com/ejbca/.... then my-ejbca.com needs to be in the hosts file of the host of the ejbca, even if youre running ejbca from within a container.

whats odd is that for signserver you dont need to do this. only for ejbca.

the other oddity is the level of client authentication needed to consume ejbca rest services. some of the rest calls are read only e.g. retrieving cert chains for issued certs etc. IMO I should be able to consume these without authentication.

Reading the ejbca doc about user authentication, it says to use the superadmin account for rest calls - maybe not! What I did instead was to create a new role that could only do "view end entities and certificates". I added a entity to that role and they could then consume rest to retrieve certs but do nothing else.

What Im doing is signing code and retrieving back full certificate chain up to but not including the root ca. To do this I call the signserver rest call and get back the signature and the signer cert then I need to call the ejbca rest to retrieve the issuing CA cert.

[primetomas]

I agree, we should generally not document to use superadmin, but point to using the fine grained authentication. Can you point me to the documentation section and I will improve it.

Leaving even a search an API open for unathenticated requests is not something we will do. It would likely be flagged as an information disclosure vulnerability by compliance driven users. I don't know though, can you use a PublicAccessAuthentication token in the role for this?