how to generate a ra-tls certificate by a provided CA using ra_tls_attest.so?

[tiagorvmartins]

Sorry if this question doesn't make sense,

But I am trying to have a client providing a certificate to authenticate himself to a https server that is running inside an enclave.
This enclave uses ra_tls_attest.so library to generate the server certificate containing all the sgx quote.
I did manage to have a connection but without client providing any certificate and skipping client certificate verification all together.

So I guess my question is, how can generate this server certificate (containing the sgx quote) signed by the CA?
Because then I could also generate a client certificate based on the same CA and use it as authentication.

I have read this in the docs:
The three Gramine-native interfaces described above are quite limited in their functionality. For example, RA-TLS currently creates only self-signed X.509 certificates that may not fit well in traditional Public Key Infrastructure (PKI) flows.

So I guess I will not be able to achieve what I am trying to do?
Thank you!

[dimakuv]

So I guess my question is, how can generate this server certificate (containing the sgx quote) signed by the CA?

Currently, no such scenario is supported. We did think about this, and we admit that this can be a useful feature. But it's not in our near-future plans.

In the meantime, maybe you want to look at Edgeless Marblerun? It integrates with Gramine and it provides a classic PKI infrastructure with normal certificates, at the cost of a special "Coordinator" master node that hides the complexity of SGX Quotes.

You can find more technical info here:

• https://github.com/edgelesssys/marblerun
• https://docs.edgeless.systems/marblerun

[tiagorvmartins]

Thank you for your answer and support @dimakuv

My client is in Go (outside sgx) and to make ra-tls working, I had to specify InsecureSkipVerify in tls.Config.

This flag states the following: InsecureSkipVerify controls whether a client verifies the server's certificate chain and host name. If InsecureSkipVerify is true, crypto/tls accepts any certificate presented by the server and any host name in that certificate. In this mode, TLS is susceptible to machine-in-the-middle attacks unless custom verification is used. This should be used only for testing or in combination with VerifyConnection or VerifyPeerCertificate.

I believe if I wrap my client inside an enclave, and do VerifyConnection on both ends calling my custom callback to check the sgx quote measurements on each side of each opposite enclave, it could work and even be secure? I guess that could be considered a TLS mutual authentication?

[dimakuv]

I believe if I wrap my client inside an enclave, and do VerifyConnection on both ends calling my custom callback to check the sgx quote measurements on each side of each opposite enclave, it could work and even be secure? I guess that could be considered a TLS mutual authentication?

Yes, exactly.

P.S. Regarding InsecureSkipVerify -- yes, you have to specify it. Think of it this way: RA-TLS uses the X.509 certificate format only as a convenience wrapper around the SGX quote. By itself, this X.509 certificate is basically useless; the only benefit of using classic certs is so that we can easily re-use SSL/TLS libraries like OpenSSL, mbedTLS, WolfSSL. But the actual verification of trustworthiness comes not from the certificate chain (there is none, as the cert is self-signed), but from the SGX quote examination.

[tiagorvmartins]

Thank you! Understood now!

[monavij]

BTW you can still use RA-TLS to establish that you are indeed running in an enclave and then using secret provisioning, provision the CA signed cert for future use. That is what Edgeless marblerun does anyway.