Let me correct myself first. my ingress rule was matching all paths, so the ingress rule that cert manager adds (for the path well-known/acme-challenge/<some-hash>) is not reachable. If you follow the example in istio.io, you may not have to do (1).
If you want to have ingress rules to match all paths like I did (I was using ingress-gateway, btw), you can add a match rule for .well-known path to route to the challenge service that cert manager created. However, as you see, you’ll need to find the service name at that time, so this solution doesn’t works for key rotation. I don’t know other better solution, except try to keep the ingress match rule more conservative.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin
spec:
hosts:
- "httpbin.example.com"
gateways:
- httpbin-gateway
http:
- match:
- uri:
prefix: /.well-known
route:
destination: cm-acme-http-solver-wgvxd
- match:
route:
destination: httpbin
Number (2) is the problem when mTLS is enabled (globally) for your mesh. Istio installation may add a default destination rule that turn on mTLS for all service. However, as mentioned above, the acme solver doesn’t have sidecar so that rule will also make the service unreachable (503). You may add a destination rule to disable mTLS for that service specifically (or even the whole istio-system namespace, and enable for those that needed, e.g telemetry and policy)