Working on my project, I encountered the need for a reverse proxy solution. Initially, we used Nginx, but faced challenges in organizing the process for certificate generation. At the early stage of the project, we couldn't afford to spend time on development and needed a ready-to-use solution for working with Let's Encrypt or other providers. That's when I decided to explore Traefik as an alternative to Nginx. In this article, I will share my experience integrating Traefik into my project and discuss how it met the requirements for a reverse proxy and SSL certificate management.

My project required reverse proxy functionality with automatic generation and maintenance of SSL certificates for various types of domains, including regular and wildcard domains. These domains could be created automatically, so it was crucial to have a quick and straightforward generation process. Traefik fully met these requirements.

To give you an idea of how Traefik was configured, here is a sample of the docker-compose.yml and frontend.yml files (with sensitive information replaced with placeholders):

# docker-compose.yml

traefik:
    image: traefik:v2.9
    hostname: traefik
    container_name: traefik
    command:
      - --log.level=DEBUG
      - --providers.file.directory=/configs
      - --providers.file.watch=true
     # Set up Let's Encrypt with HTTP challenge
      - --certificatesResolvers.myresolver.acme.email=myemail@example.com
      - --certificatesresolvers.myresolver.acme.httpchallenge=true
      - --certificatesresolvers.myresolver.acme.httpchallenge.entrypoint=web
      - --certificatesResolvers.myresolver.acme.storage=/letsencrypt/acme.json
		# Set up LetsEncrypt with dnschallenge
      - --certificatesresolvers.wildcard.acme.dnschallenge=true
      - --certificatesresolvers.wildcard.acme.dnschallenge.provider=cloudflare
      - --certificatesresolvers.wildcard.acme.email=admin@pagels.dev
      - --certificatesresolvers.wildcard.acme.storage=/letsencrypt/acme.json
     # HTTPS redirection
      - --entryPoints.web.address=:80
      - --entryPoints.web.http.redirections.entryPoint.to=websecure
      - --entryPoints.web.http.redirections.entryPoint.scheme=https
      - --entryPoints.websecure.address=:443
    environment:
      - CF_DNS_API_TOKEN=placeholder_token
    ports:
      - 80:80
      - 443:443
    volumes:
        - letsencrypt:/letsencrypt
				- ./data/traefik:/configs
networks:
  - mynetwork

# frontend.yml

http:
  routers:
    myapp:
      rule: "HostRegexp(`example.com`, `{subdomain:[a-z]+}.example.com`)"
      priority: 1
      service: frontend
      middlewares:
        - removeHost
      tls:
        certResolver: "wildcard"
        domains:
          - main: "example.com"
            sans:
              - "*.example.com"

    my-app:
      rule: "Host(`my.example.com`)"
      priority: 2
      service: office
      tls:
        certResolver: "myresolver"
        domains:
          - main: "my.example.com"

  middlewares:
    removeHost:
      headers:
        customRequestHeaders:
          X-Forwarded-Host: ""

  services:
    frontend:
      loadBalancer:
        servers:
          - url: "http://frontend:53000/"
    office:
      loadBalancer:
        servers:
          - url: "http://office:53001/"
   

In the provided configuration, two different certResolvers are used for SSL certificate management. The first certResolver, "wildcard," is configured for DNS challenge and allows for the issuance of wildcard certificates. The second certResolver, "myresolver," operates with HTTP challenge and is used for generating certificates for domains that do not require wildcard certificates.

The DNS challenge is used for issuing wildcard certificates. It requires the client to prove ownership of the domain by creating a specific DNS record. This method is suitable when you need to secure multiple subdomains with a single certificate (e.g., *.example.com). The configuration for the "wildcard" certResolver specifies the DNS challenge, the DNS provider (Cloudflare in this case), and the storage location for the certificates.

On the other hand, the HTTP challenge is a simpler method that requires the client to prove ownership of the domain by serving a specific file at a specific URL on the domain. It is suitable for securing individual domains and subdomains without the need for a wildcard certificate. In the configuration for the "myresolver" certResolver, the HTTP challenge and storage location for the certificates are specified.

In summary, Traefik proved to be a valuable tool in my project, providing a seamless reverse proxy solution and SSL certificate management. Depending on your project's needs, you can choose the appropriate certResolver and challenge method for managing SSL certificates. I hope my experience and the provided code samples can help others looking for a similar solution.