|
4 | 4 |
|
5 | 5 | ## How It Works |
6 | 6 |
|
7 | | -When a client successfully completes an ACME challenge, `acme-proxy` forwards the certificate signing request to an external certificate authority (CA) that supports External Account Binding (EAB). The external CA signs the certificate and returns it to the client through `acme-proxy`. |
| 7 | +`acme-proxy` runs as an ACME server inside your enterprise environment, acting as an intermediary between your internal infrastructure and an external certificate authority service (such as Sectigo). When a client successfully completes an ACME challenge, `acme-proxy` forwards the certificate signing request to an external certificate authority (CA) that supports External Account Binding (EAB). The external CA signs the certificate and returns it to the client through `acme-proxy`. |
| 8 | + |
| 9 | +**Certificate Request Flow:** |
| 10 | + |
| 11 | +1. Your internal server (behind a firewall perimeter) requests a certificate from `acme-proxy` using standard ACME clients like certbot, acme.sh or cert-manager.io if you're using Kubernetes. |
| 12 | +2. `acme-proxy` presents cryptographic challenges to verify domain ownership |
| 13 | +3. Once validation succeeds, `acme-proxy` forwards the certificate signing request to your external CA using External Account Binding (EAB) |
| 14 | +4. The external CA signs the certificate |
| 15 | +5. `acme-proxy` retrieves the certificate bundle and returns it to your server |
| 16 | + |
| 17 | + |
8 | 18 |
|
9 | 19 | **Note:** LetsEncrypt does not support EAB. However, commercial CAs such as Sectigo and ZeroSSL do. |
10 | 20 |
|
@@ -40,20 +50,6 @@ Using ACME with commercial CAs in enterprise environments provides several advan |
40 | 50 | - Leverage standard ACME clients (Certbot, acme.sh, cert-manager.io) for certificate issuance, automatic renewals. |
41 | 51 | - Enable self-service certificate requests for development teams |
42 | 52 |
|
43 | | -## ACME Proxy Workflow |
44 | | - |
45 | | -`acme-proxy` runs as an ACME server inside your enterprise environment, acting as an intermediary between your internal infrastructure and an external certificate authority service (such as Sectigo). |
46 | | - |
47 | | -**Certificate Request Flow:** |
48 | | - |
49 | | -1. Your internal server (behind a firewall perimeter) requests a certificate from `acme-proxy` using standard ACME clients like certbot, acme.sh or cert-manager.io if you're using Kubernetes. |
50 | | -2. `acme-proxy` presents cryptographic challenges to verify domain ownership |
51 | | -3. Once validation succeeds, `acme-proxy` forwards the certificate signing request to your external CA using External Account Binding (EAB) |
52 | | -4. The external CA signs the certificate |
53 | | -5. `acme-proxy` retrieves the certificate bundle and returns it to your server |
54 | | - |
55 | | - |
56 | | - |
57 | 53 | ## Quick Start |
58 | 54 |
|
59 | 55 | ```sh |
@@ -118,7 +114,6 @@ The most important parts of the config are - |
118 | 114 | "account_email": "", |
119 | 115 | "eab_kid": "", |
120 | 116 | "eab_hmac_key": "", |
121 | | - "certlifetime": 30, |
122 | 117 | "metrics": { |
123 | 118 | "enabled": true, |
124 | 119 | "port": 9234, |
|
0 commit comments