Support IP identities for attested TLS certificates

[ameba23]

attested-tls models certificate identity as strings:

• primary_name: String
• subject_alt_names: Vec<String>

That works for DNS hostnames, but for deployments where clients connect by IP address instead of hostname, rustls/webpki expects the server certificate to contain an actual IP SAN. A DNS SAN containing a string like "203.0.113.10" is not equivalent and will fail name verification when the client connects by IP.

In the current API, AttestedCertificateResolver::new(...) only accepts string names, so callers cannot express whether an identity is a hostname or an IP address.

As a result, projects using attested-tls cannot correctly generate attested certificates for IP-only endpoints.

This is not really an issue when using nested-tls, as the inner session inherits the hostname from the outer session.

But when we only have the inner session, it can be tricky.

I noticed this when trying to integrate with attested-tls-proxy in flashbots/attested-tls-proxy#152

[ameba23]

The difficulty heres is that we use ra_tls to build the certificate parameters, which only accepts SANs as &str and assumes they are SanType::DnsName:

https://github.com/Dstack-TEE/dstack/blob/3a456dd6e332509f97e7ef3d83758ca3ea35770c/ra-tls/src/cert.rs#L374-L378

But since this builder produces a rcgen::CertificateParams we can modify the subject_alt_names after building but before signing. This is a little bit hacky. The alternative would be to make a PR to ra_tls.

[ameba23]

Update: I decided this is worth PRing to ra-tls, and it has been merged: Dstack-TEE/dstack#673

I will leave this issue open until this is updated in this repo.