ct_monitor: Use HTTP endpoint instead of pRPC for acme-info

[h4x3rotab]

Summary

• Fix ct_monitor to use HTTP /acme-info endpoint instead of pRPC
• The gateway exposes /acme-info as HTTP, but ct_monitor was calling pRPC which caused 405 errors
• Root cause: gateway pRPC uses trim: "Tproxy." so it expects Tproxy.* method names
• Removes unused dstack-gateway-rpc and ra-rpc dependencies

Test plan

• Build: cargo build --release -p ct_monitor
• Test against production gateway: ./target/release/ct_monitor --gateway-uri https://gateway.dstack-pha-prod7.phala.network --domain dstack-pha-prod7.phala.network
• Verified it successfully fetches public keys and checks certificate logs

🤖 Generated with Claude Code

In general, the fix is to ensure TLS certificate validation is enabled for the reqwest client used in refresh_known_keys. This is done by not calling danger_accept_invalid_certs(true) (relying on the secure default) or explicitly setting it to false. This preserves existing functionality (an HTTPS GET to /acme-info and JSON parsing) while restoring protection against MITM attacks.

The best minimal change in ct_monitor/src/main.rs is to configure the client as:

let client = reqwest::Client::builder()
    .danger_accept_invalid_certs(false)
    .build()
    .context("failed to build http client")?;

This keeps the structure and error handling intact and simply removes the insecure behavior. We do not add any new imports or change other logic; we only adjust the TLS configuration at line 60. If RA-TLS or more advanced verification is to be added later, it can be implemented on top of this secure baseline, but for now we just ensure standard certificate verification is not disabled.

Concretely:

• Edit ct_monitor/src/main.rs, within impl Monitor { async fn refresh_known_keys(&mut self) -> Result<()> { ... } }.
• Replace the .danger_accept_invalid_certs(true) call with .danger_accept_invalid_certs(false) (or remove the call entirely; here we choose false to be explicit, matching the background’s “GOOD” example).
• Keep the existing comment or adjust it to reflect that the temporary insecure workaround is gone; however, to minimize non-functional change, we can leave the comment in place if desired.

No additional methods, imports, or definitions are required for this fix.