Ephemeral EJBCA Container + EJBCA Go Client = tls: failed to verify certificate

[ToddBerliner]

I'm running an ephemeral docker container on an AWS EC2 instance with:

docker run -it --rm -p 80:8080 -p 443:8443 -h [my AWS EC2 hostname] -e TLS_SETUP_ENABLED="simple" keyfactor/ejbca-ce

Locally, I want to use the EJBCA Go Client to consume the REST API. I've used the RA Web interface to generate a client certificate from a locally produced CSR and in the Go code have set an ejbca.Config with CertificateFile, CAFile, KeyFile, and KeyPassword. For the CAFileI am using theManagement CA` that I downloaded from the RA Web interface as a PEM.

When I call factory.NewEJBCAClient() I get:

2023/11/14 06:07:32 [INFO] Building new EJBCA client
2023/11/14 06:07:32 [TRACE] Reading client certificate from /Users/todd.berliner/Downloads/foo-commonname-1.pem
2023/11/14 06:07:32 [TRACE] Found CERTIFICATE
2023/11/14 06:07:32 Didn't find private key in client certificate file, looking in /Users/todd.berliner/Downloads/foo-privkey-1.pem
2023/11/14 06:07:32 [TRACE] Private key is not protected
2023/11/14 06:07:32 [TRACE] Found PRIVATE KEY
2023/11/14 06:07:32 [DEBUG] Found client certificate and private key
2023/11/14 06:07:32 [DEBUG] Added CA certificate from /Users/todd.berliner/Downloads/ManagementCA.pem to HTTP transport trusted CA pool
2023/11/14 06:07:32 [INFO] Getting EJBCA V1 Certificate Endpoint Status
2023/11/14 06:07:32 [INFO] Preparing a GET request to path 'https://ec2-18-118-208-171.us-east-2.compute.amazonaws.com/ejbca/ejbca-rest-api/v1/certificate/status'
2023/11/14 06:07:33 Get "https://ec2-18-118-208-171.us-east-2.compute.amazonaws.com/ejbca/ejbca-rest-api/v1/certificate/status": tls: failed to verify certificate: x509: certificate signed by unknown authority

I think this means that I haven't properly configured my client (my local Mac) with "...this certificate be registered with the client as a root of trust" as described in the Getting Started With the Go Client Library. I did use Keychain Access to add the Management CA and marked it as trusted.

Any pointers? Can I consume the REST API from this ephemeral container?

[primetomas]

I can answer one of your questions.
Generally you may find it hard to use TLS_SETUP_ENABLED="simple" if you want to use the REST API. Because this disabled client certificate authentication, you need to set up OAuth instead, which is an Enterprise feature.
If you start your ephemeral container with TLS_SETUP_ENABLED="true" instead there is no problem using the REST API.
But, you need to fix the "untrusted root" issue. I'm not a Go expert though, so I don't have an answer to that.

[ToddBerliner]

Now I've got access to /adminweb and /ra and I've downloaded my SuperAdmin.p12

However now when trying to achieve a TLS handshake, I think the ManagementCA I've downloaded is different than what the server is presenting. When I do curl -vk https://XXX/ejbca/ejbca-rest-api/v1/certificate/status I see

Server certificate:
*  subject: UID=c-04sa27qdo6s8pe4q6; CN=ec2-3-144-42-184.us-east-2.compute.amazonaws.com; O=EJBCA Container Quickstart
*  start date: Nov 14 17:17:33 2023 GMT
*  expire date: Nov 13 17:08:08 2025 GMT
*  issuer: UID=c-04sa27qdo6s8pe4q6; CN=ManagementCA; O=EJBCA Container Quickstart
*  SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.

But when I inspect the ManagementCA.pem I see:

todd.berliner@HW-0210 Downloads % openssl x509 -text -noout -in ManagementCA\(1\).pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            3a:67:e3:0a:18:a3:ef:77:2f:cd:80:be:4c:75:b2:98:f8:61:66:78
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: UID = c-04sa27qdo6s8pe4q6, CN = ManagementCA, O = EJBCA Container Quickstart
        Validity
            Not Before: Nov 14 17:17:33 2023 GMT
            Not After : Nov 13 17:17:32 2033 GMT
        Subject: UID = c-04sa27qdo6s8pe4q6, CN = ManagementCA, O = EJBCA Container Quickstart

Don't the CN values need to match for a successful TLS verification?

[primetomas]

Looks good to me. You're server certificate have the CN of your cloud host,
ec2-3-144-42-184.us-east-2.compute.amazonaws.com
It is signed by the Management CA:
issuer: UID=c-04sa27qdo6s8pe4q6; CN=ManagementCA; O=EJBCA Container Quickstart

This issuer matches the subject of the Managment CA certificate:
Subject: UID = c-04sa27qdo6s8pe4q6, CN = ManagementCA, O = EJBCA Container Quickstart
(just different tool used to print the values, hence difference between ; or ,)

Looks correct to me. A two level Hierarchy:

• Management CA (self signed Root)
  -- Server certificate (leaf certificate signed by the root)

[ToddBerliner]

Understood. Thank you @primetomas!

[ToddBerliner]

I was using the wrong CA file when specifying the ejbca.Config.CAFile. I was using the RootCA rather than the actual Server certificate. Specifying the server certificate resolved the TLS error. See the docs here.