Wildcard certificate config in command vs labels

Traefik Traefik v2 (latest)
1

I want a wildcard certificate.

In examples for the traefik container's docker-compose.yml, I've seen this:

command:
  - --entrypoints.websecure.http.tls=true
  - --entrypoints.websecure.http.tls.certResolver=myresolver
  - --entrypoints.websecure.http.tls.domains[0].main=${DOMAIN}
  - --entrypoints.websecure.http.tls.domains[0].sans=*.${DOMAIN}

or this:

labels:
  - traefik.http.routers.wildcard.tls.certresolver=myresolver
  - traefik.http.routers.wildcard.tls.domains[0].main=${DOMAIN}
  - traefik.http.routers.wildcard.tls.domains[0].sans=*.${DOMAIN}

(Assume myresolver and DOMAIN are defined correctly.)

What is the difference, and which should I use?

2

As you learned yesterday, there is global static config and more local dynamic config, with labels usually related to target services in a container.

If the cert is used by multiple services, I would place it on static command to be used globally, otherwise on the related service dynamic labels config.

1 Like
3

Thanks once again bluepuma.

The routers bit confused me - I wasn't sure whether the two config blocks actually did the same thing.

4

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

5
  1. Command-based configuration: With command-based configuration, you typically use a command-line interface (CLI) or configuration file to specify the details of your wildcard certificate. This approach involves running commands or executing scripts to generate and configure the certificate. For example, if you're using the OpenSSL toolkit, you might generate a wildcard certificate with a command like this:
openssl req -newkey rsa:2048 -nodes -keyout domain.key -x509 -days 365 -out domain.crt -subj "/C=US/ST=State/L=City/O=Organization/CN=*.example.com"

In this command, you're specifying the subject (/C=US/ST=State/L=City/O=Organization/CN=*.example.com) to generate a wildcard certificate for the domain *.example.com. The specific commands and tools can vary depending on the certificate authority (CA) or the infrastructure you're working with.
2. Label-based configuration: Label-based configuration involves adding labels or annotations to your infrastructure resources, such as Kubernetes deployments or services. These labels serve as metadata that can be used by an automated process or tool to generate and manage wildcard certificates. For instance, you might use a tool like cert-manager in Kubernetes to configure wildcard certificates using labels. You would define a custom resource, such as a Certificate resource, and specify the necessary labels in its configuration. The cert-manager controller would then watch for these labels and automatically generate and manage the corresponding wildcard certificates. Here's an example of a Certificate resource configuration using labels in Kubernetes:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-certificate
spec:
  secretName: wildcard-tls
  dnsNames:
    - "*.example.com"
  issuerRef:
    name: letsencrypt
    kind: ClusterIssuer

In this example, the dnsNames field specifies the wildcard domain ("*.example.com") for which the certificate should be issued. The cert-manager controller, based on the specified labels and issuer reference, would generate the certificate and store it securely in the specified secretName.

Both command-based and label-based configurations have their merits. Command-based configurations are generally more flexible and can be used across different infrastructure setups. On the other hand, label-based configurations are more automated and integrate well with orchestration frameworks like Kubernetes.

The choice between these approaches depends on your specific use case, infrastructure setup, and the tools or platforms you are working with.

1 Like