[GH-ISSUE #3] Unbundle certificate? #1

Closed
opened 2026-02-25 21:30:47 +03:00 by kerem · 4 comments
Owner

Originally created by @carloscarnero on GitHub (May 1, 2020).
Original GitHub issue: https://github.com/certera-io/certera/issues/3

Currently testing this awesome project, and got to the point where I got the certificate for the certera instance. While testing the process of getting that certificate from a remote node (using curl) for further deployment, the file I got seems to include the full certificate chain.

Currently, the endpoint I'm hitting, as per the documentation, is /api/certificate/<certificate_name>. Is there another endpoint for the unbundled certificate? If not, how about another parameter, like bundled=true|false? By default true to avoid breakage.

In the same vein, how about yet another parameter, chain=false|true, that would allow to download just the chain (or, if the chain is the same for any certificate, another endpoint altogether.)

Why the above? I deploy certificates in dissimilar systems: Apache, Nginx, Icecast, and many more. Each of them have different semantics for injecting the certs: some like the bundles, others separated (Icecast even wants to have the certificate, chain and key in a single file.) So, having the option of getting all those components separately would make certera more versatile, IMO.

Originally created by @carloscarnero on GitHub (May 1, 2020). Original GitHub issue: https://github.com/certera-io/certera/issues/3 Currently testing this **awesome** project, and got to the point where I got the certificate for the certera instance. While testing the process of getting that certificate from a remote node (using `curl`) for further deployment, the file I got seems to include the full certificate chain. Currently, the endpoint I'm hitting, as [per the documentation](https://docs.certera.io/#certificates-api), is `/api/certificate/<certificate_name>`. Is there another endpoint for the unbundled certificate? If not, how about another parameter, like `bundled=true|false`? By default `true` to avoid breakage. In the same vein, how about yet another parameter, `chain=false|true`, that would allow to download just the chain (or, if the chain is the same for *any* certificate, another endpoint altogether.) Why the above? I deploy certificates in dissimilar systems: Apache, Nginx, Icecast, and many more. Each of them have different semantics for injecting the certs: some like the bundles, others separated (Icecast even wants to have the certificate, chain and key in a single file.) So, having the option of getting all those components separately would make certera more versatile, IMO.
kerem 2026-02-25 21:30:47 +03:00
Author
Owner

@certeraio commented on GitHub (May 1, 2020):

Hi @carloscarnero! Thanks for the input and feedback. Greatly appreciated.

You certainly are correct that it would be more versatile. Today, the certificates endpoint returns the chain, which may not be what people want. Let me do some research on the best way to get just the certificate for the subject requested. I like the idea of the backwards compatible bundle parameter.

As for combining the key, it should be trivial to concatenate that after retrieving via curl, right?
After obtaining the certificate (whether bundled, i.e. whole chain, or single), you can do
cat key.pem cert.pem > combined.pem

<!-- gh-comment-id:622597310 --> @certeraio commented on GitHub (May 1, 2020): Hi @carloscarnero! Thanks for the input and feedback. Greatly appreciated. You certainly are correct that it would be more versatile. Today, the certificates endpoint returns the chain, which may not be what people want. Let me do some research on the best way to get just the certificate for the subject requested. I like the idea of the backwards compatible bundle parameter. As for combining the key, it should be trivial to concatenate that after retrieving via curl, right? After obtaining the certificate (whether bundled, i.e. whole chain, or single), you can do cat key.pem cert.pem > combined.pem
Author
Owner

@certeraio commented on GitHub (May 4, 2020):

Hi @carloscarnero. I've created a new release, version 2.0.2 that contains the chain parameter. The default is true (or don't specify the parameter at all) and the chain is returned (same as what it has always done). When chain=false, only a single certificate is returned.

https://github.com/certera-io/certera/releases/tag/2.0.2-beta

<!-- gh-comment-id:623735275 --> @certeraio commented on GitHub (May 4, 2020): Hi @carloscarnero. I've created a new release, version 2.0.2 that contains the `chain` parameter. The default is `true` (or don't specify the parameter at all) and the chain is returned (same as what it has always done). When `chain=false`, only a single certificate is returned. https://github.com/certera-io/certera/releases/tag/2.0.2-beta
Author
Owner

@carloscarnero commented on GitHub (May 4, 2020):

I confirm that this works!

However, I seem to missunderstand the documentation, in particular passing the query string parameters. The example shows

curl https://<your_certera_site_hostname>/api/certificate/<certificate_name> \
  -H "apiKey:<your_api_key>" \
  -d "staging=true&format=pfx&pfxPassword=$3cr3t"

But I think that -d sends the data in a POST request.

Adding the parameters to the URL works as expected or, alternatively, including the -G parameter that forces the request to be a GET. So I think the above block of documentation should be

curl https://<your_certera_site_hostname>/api/certificate/<certificate_name> \
  -H "apiKey:<your_api_key>" \
  -d "staging=true&format=pfx&pfxPassword=$3cr3t" -G

EDIT: I took the liberty of creating a pull request at certera-io/docs#1 that includes the -G parameter. Not sure if its OK, but... YOLO.

<!-- gh-comment-id:623765276 --> @carloscarnero commented on GitHub (May 4, 2020): I confirm that this works! However, I seem to missunderstand [the documentation](https://docs.certera.io/#certificates-api), in particular passing the query string parameters. The example shows ```bash curl https://<your_certera_site_hostname>/api/certificate/<certificate_name> \ -H "apiKey:<your_api_key>" \ -d "staging=true&format=pfx&pfxPassword=$3cr3t" ``` But I think that `-d` [sends the data in a `POST` request](https://curl.haxx.se/docs/manpage.html#-d). Adding the parameters to the URL works as expected or, alternatively, including the `-G` parameter that [forces the request to be a `GET`](https://curl.haxx.se/docs/manpage.html#-G). So I _think_ the above block of documentation should be ```bash curl https://<your_certera_site_hostname>/api/certificate/<certificate_name> \ -H "apiKey:<your_api_key>" \ -d "staging=true&format=pfx&pfxPassword=$3cr3t" -G ``` **EDIT**: I took the liberty of creating a pull request at certera-io/docs#1 that includes the `-G` parameter. Not sure if its OK, but... YOLO.
Author
Owner

@certeraio commented on GitHub (May 5, 2020):

Hi @carloscarnero
You are correct. I missed that parameter. Thanks for catching that. I had read this on my phone and fixed it before seeing your edit and PR. Thanks for submitting the PR, but I have closed it since I had previously fixed it!

<!-- gh-comment-id:623813069 --> @certeraio commented on GitHub (May 5, 2020): Hi @carloscarnero You are correct. I missed that parameter. Thanks for catching that. I had read this on my phone and fixed it before seeing your edit and PR. Thanks for submitting the PR, but I have closed it since I had previously fixed it!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/certera#1
No description provided.