Skip to content

Add Support for DNS-01 Challenge in Let's Encrypt Certificate Validation#18

Open
Freekers wants to merge 7 commits intozkVerify:mainfrom
Freekers:main
Open

Add Support for DNS-01 Challenge in Let's Encrypt Certificate Validation#18
Freekers wants to merge 7 commits intozkVerify:mainfrom
Freekers:main

Conversation

@Freekers
Copy link
Copy Markdown

@Freekers Freekers commented Aug 25, 2025

Add DNS-01 Challenge Support for Let's Encrypt SSL Certificates

This change addresses common deployment scenarios where port 80 is already in use by web servers or reverse proxies, and provides better flexibility for SSL certificate validation.

Summary

This pull request adds DNS-01 challenge support alongside the existing HTTP-01 challenge support for Let's Encrypt certificate validation in boot node deployments. Users can now choose their preferred validation method during initialization.

The HTTP-01 challenge requires port 80 to be available, which isn't always possible when other services are running on the same server. DNS-01 challenges use DNS TXT records for validation, removing port requirements and enabling certificate generation behind firewalls or NAT.

What Changed

Configuration Updates

  • Updated env/.env.boot-node.testnet.template: Added ACME_CHALLENGE_TYPE and ACMESH_DNS_API_CONFIG variables for DNS challenge configuration
  • Modified compose_files/docker-compose-boot-node.yml: Added environment variable mappings to pass challenge type and DNS provider configuration to the acme-companion container

Script Changes

Added to scripts/utils.sh:

  • select_acme_challenge_type() - Interactive prompt explaining HTTP-01 vs DNS-01 methods
  • configure_dns_provider() - Provider selection with support for popular DNS services
  • configure_dns_credentials() - Provider-specific credential collection with proper JSON formatting

Updated scripts/init.sh:

  • Integrated DNS-01 configuration into the boot node setup process
  • Added conditional DNS provider setup when DNS-01 is selected
  • Enhanced environment variable validation for new DNS-related variables

How It Works

During boot node setup, users choose between validation methods:

HTTP-01 Challenge (Default):

  • Validates domain ownership through HTTP requests on port 80
  • Requires port 80 to be accessible and available
  • Works well for dedicated servers with no port conflicts

DNS-01 Challenge (New):

  • Validates domain ownership through DNS TXT records
  • No port requirements - works when port 80 is unavailable or blocked
  • Requires API access to your DNS provider
  • Good for complex network setups or shared hosting

When DNS-01 is selected, the setup process walks users through provider selection, credential entry, and automatic configuration generation.

DNS Provider Support

The implementation includes setup instructions for common providers:

  • Cloudflare (dns_cf) - API token or global API key with email
  • AWS Route53 (dns_aws) - Access key ID, secret access key, and region
  • DigitalOcean (dns_do) - API token
  • Linode (dns_linode) - API token
  • OVH (dns_ovh) - Application key, secret, consumer key, and endpoint
  • Gandi (dns_gandi_livedns) - API key
  • Namecheap (dns_namecheap) - API user, key, and client IP
  • GoDaddy (dns_godaddy) - API key and secret
  • Custom providers - Manual entry for any provider supported by acme.sh

Each provider includes specific credential requirements and links to relevant API documentation.

Technical Details

DNS API credentials are stored as properly escaped JSON in the ACMESH_DNS_API_CONFIG environment variable. The implementation handles cross-platform compatibility and includes proper validation of user inputs and configuration format.

Backward Compatibility

Existing deployments continue working unchanged. The default challenge type remains HTTP-01, so current users see no difference unless they explicitly choose DNS-01.

Testing

All modified shell scripts pass syntax validation. The Docker Compose configuration properly passes new environment variables to the acme-companion container. Interactive functions have been tested for user experience and cross-platform compatibility.

Benefits

This change makes zkverify boot node deployment more flexible by supporting different network configurations while maintaining the straightforward setup process. DNS-01 validation is particularly useful in enterprise environments where port 80 might be restricted or already in use.

Copilot AI review requested due to automatic review settings August 25, 2025 11:48
@Freekers Freekers requested a review from a team as a code owner August 25, 2025 11:48
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Comment thread scripts/init.sh
if [ "${NODE_TYPE}" = "boot-node" ]; then
create_node_key
set_acme_vhost
set_acme_challenge_type
Copy link
Copy Markdown
Contributor

@ysibirski ysibirski Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this one should be deleted. Looks like leftovers from previous implementation. This function is not defined and seems like you are using select_ one instead

Suggested change
set_acme_challenge_type

environment:
- "DEFAULT_EMAIL=${ACME_DEFAULT_EMAIL?err_unset}"
- "ACME_CHALLENGE=${ACME_CHALLENGE_TYPE?err_unset}"
- ACMESH_DNS_API_CONFIG=${ACMESH_DNS_API_CONFIG:-}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For consistency

Suggested change
- ACMESH_DNS_API_CONFIG=${ACMESH_DNS_API_CONFIG:-}
- "ACMESH_DNS_API_CONFIG=${ACMESH_DNS_API_CONFIG:-}"

Copy link
Copy Markdown
Contributor

@ysibirski ysibirski Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem may arise if your server is already listening on 80 or 443 ports for other services and you will be bringing nginx-proxy container from the compose project UP which maps ports 80 and 443 as well it will fail to start due to ports already being in use. However, if nothing is using those ports having an extra ACME challenge option is still beneficial.

However, if we remove port 80 from docker compose or use diff services for diff ACME challenges this will remove port 80 utilization for DNS-01 challenge

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly :) Would you be willing to merge this PR if I fix the small issues mentioned above? Thanks

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the PR looks very solid. But what I was trying to say is that switching to a diff ACME challenge(DNS-01) still does not remove port 80 from nginx-proxy service, that means nginx-proxy will fail to start if your other services are occupying port 80 already. To stop relying on port 80 we will need a diff nginx-service. However, just in general having an extra challenge option is beneficial to have. Thus, please go ahead and fix your PR and we will review, test it and merge it 💪

ports:
      - "80:80"
      - "443:443"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants