Requesting a wildcard certificate using local Boulder fails with feature error

I’m trying to test wildcard certificates with a local instance of Boulder. I’m using the Docker-based setup as suggested in the readme.

I have the local version of Boulder running in Docker from a pristine git clone and listening on 4000:

docker-compose up

I also have a certbot instance and I used it to request a new certificate:

certbot certonly -a standalone -d '*.test-1.com' \
    --server http://localhost:4000/directory \
    --config-dir /.../conf \
    --work-dir /.../work \
    --logs-dir /var/.../logs \
    --register-unsafely-without-email \
    --agree-tos \
    --no-verify-ssl \
    --debug -vv 

That command fails with error:

  File "...", line 368, in _get_order_and_authorizations
    raise errors.Error("The currently selected ACME CA endpoint does"
certbot.errors.Error: The currently selected ACME CA endpoint does not support issuing wildcard certificates.

From the output it seems it’s trying to connect to a v1 endpoint http://boulder:4000/terms/v1. How can I connect to the v2 directory running on localhost:4000?

The Wildcard feature is enabled in test/config/ca.json.

1 Like

Isn’t the ACME version used also somewhere in ca.json? (Or another config.)

Hi @weppos,

For ACME v2 you need to use --server http://localhost:4001/directory to match the listenAddress of the WFE2 service configured in test/config/wfe2.json.

The API versions are separated by frontend and port (wfe vs wfe2 and 4000 vs 4001 respectively).

Hope that helps!

2 Likes

So it isn’t a configuration thingy? :open_mouth:

The components behind the WFE are the same whether you are/aren't using ACMEv2. There are some backend RPCs that are only used by the new API (e.g. the Storage Authority's NewOrder RPC) but there isn't an API division throughout all of the components beyond the WFE/WFE2.

1 Like

Ah, I see. :slight_smile:

I was almost sure it was a trivial answer, I just could not figure it out. I tried different prefixes, but I did not realize docker was instead listening on different ports.

Thanks @cpu.

1 Like

That's totally our fault :slight_smile: I opened a quick PR on the README to make it clearer there are two ports for the two API versions: README: Mention ACME v2 API endpoint port by cpu · Pull Request #3823 · letsencrypt/boulder · GitHub

Thanks for flagging the missing information!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.