test-as.sgx.trustedservices.intel.com reject the TLS connection

test-as.sgx.trustedservices.intel.com reject the TLS connection

I just received the access confirmation for test-as.sgx.trutedservices.intel.com  but when I try to test it by:

"curl -v --tlsv1.2 --key ./testCertKey.pem --cert ./testCert.pem https://test-as.sgx.trustedservices.intel.com:443/attestation/sgx/v2/sig... "

The IAS will terminal the TCP connection upon the client has sent "Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message"  handshake messages.  Curl doesn't even get a chance to send in the "Get" request to IAS for processing.   I have check that both the private key and the cert are correct and the cert is the same one I included in the access request for the test environment.   It seems like my cert is not trusted by test-as.sgx.trustedservices.intel.com. 

 

My question is, do I have to wait a few days before the registration kick into effect? If not then where do I go for support?

 

Thanks,

Eddie.

 curl --verbos --tlsv1.2 --key ./dev_builds2/testCertKey.pem --cert ./testCert.pem https://test-as.sgx.trustedservices.intel.com:443/attestation/sgx/v2/sig... -v

*   Trying 52.0.160.62...

* TCP_NODELAY set

* Connected to test-as.sgx.trustedservices.intel.com (52.0.160.62) port 443 (#0)

* ALPN, offering http/1.1

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

* successfully set certificate verify locations:

*   CAfile: /etc/pki/tls/certs/ca-bundle.crt

  CApath: none

* TLSv1.2 (OUT), TLS header, Certificate Status (22):

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* TLSv1.2 (IN), TLS handshake, Server hello (2):

* TLSv1.2 (IN), TLS handshake, Certificate (11):

* TLSv1.2 (IN), TLS handshake, Server key exchange (12):

* TLSv1.2 (IN), TLS handshake, Request CERT (13):

* TLSv1.2 (IN), TLS handshake, Server finished (14):

* TLSv1.2 (OUT), TLS handshake, Certificate (11):

* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):

* TLSv1.2 (OUT), TLS handshake, CERT verify (15):

* TLSv1.2 (OUT), TLS change cipher, Client hello (1):

* TLSv1.2 (OUT), TLS handshake, Finished (20):

* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to test-as.sgx.trustedservices.intel.com:443

* Closing connection 0

curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to test-as.sgx.trustedservices.intel.com:443

18 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I'm having the same problem. Any help will be greatly appreciated. (I filed for a development services ticket last week, but the problem is still not fixed.)

For the record, I've followed the directions given in https://software.intel.com/en-us/articles/certificate-requirements-for-i... and https://software.intel.com/en-us/articles/how-to-create-self-signed-cert... when I create the client certificate for registration.

We are looking into this.

Just wanted to know if there's any update on this issue? Will be happy to submit a different certificate if that will help.

Curious if it's working for anyone at all? If yes, please tell us about your SSL client. (I can confirm that it doesn't work with OpenSSL or python cryptography library.)

 

Sumen .T, apparently Intel didn't deploy my cert to the correct environment.  They have since corrected the issue and update their backend.  I can get the proper response from their "test-as" server now.   Rerun your test and, it may work for you as well.  

 

 

Thanks Eddie. My old certificate had expired, so I submitted a new certificate about 2 weeks back (the new certificate has the same subject-name and private-key, just the x509 expiration date and serial number are different.) It seems that Intel has just added the new certificate on the server without removing the old one, and the server still aborts the connection (probably because during validation, it finds the old certificate before the new one, and doesn't try any other certificate).

I still cannot connect to test-as.sgx.trustedservices.intel.com.

same problem here.

days passed. is there any one can help? my renewed certificate is not working at all. 

If this is the speed with this Intel plans to handle remote attestation related issues, I guess everyone is better off staying away from SGX. I just informed our GM it's not a usable technology, at least not in the banking/finance area where reliability/fault-tolerance is crucial.

Good luck to you guys. (Also, please delete my account.)

Quote:

John M. (Intel) wrote:

We are looking into this.

 

any follow-ups? the IAS service is so much critical and now it causes a single point of failure!

Quote:

yu d. wrote:

Quote:

John M. (Intel) wrote:

 

We are looking into this.

 

 

 

any follow-ups? the IAS service is so much critical and now it causes a single point of failure!

Yes. The first reports of this issue were resolved by deploying the certs to the dev server. However, since then it appears that this is more widespread than originally thought. It's been escalated back to the IAS team for resolution.

Quote:

yu d. wrote:

any follow-ups? the IAS service is so much critical and now it causes a single point of failure!

It appears your renewal/update was submitted under a different email address than the you used originally, and that caused this to be processed as a new onboarding. We will get this straightened out, and we're looking into ways to improve the forms to eliminate this sort of uncertainty.

NO my two requests are different.

First I requested for a renewal with SGX Ticket 03432906 with my company email address.

The renewed license does not work and then I saw this thread and understood it's caused by renewal. So I requested for the second one using my personal email address Case#: 03437980.

 

Quote:

John M. (Intel) wrote:

Quote:

yu d. wrote:

 

any follow-ups? the IAS service is so much critical and now it causes a single point of failure!

 

 

It appears your renewal/update was submitted under a different email address than the you used originally, and that caused this to be processed as a new onboarding. We will get this straightened out, and we're looking into ways to improve the forms to eliminate this sort of uncertainty.

 

NO my two requests are different.

First I requested for a renewal with SGX Ticket 03432906 with my company email address.

The renewed license does not work and then I saw this thread and understood it's caused by renewal. So I requested for the second one using my personal email address Case#: 03437980.

Aha. Thank you for clarifying this. I will have the team get this sorted out.

 

We believe we have identified the root causes for each of the issues reported in this thread. As they don't all have the same cause, we'll be reaching out to you all individually.

In addition to fixing the issues, there are some changes we can make in our own processes to help identify potential problems sooner rather than later.

Quote:

John M. (Intel) wrote:

We believe we have identified the root causes for each of the issues reported in this thread. As they don't all have the same cause, we'll be reaching out to you all individually.

In addition to fixing the issues, there are some changes we can make in our own processes to help identify potential problems sooner rather than later.

 

Thanks  John!

Leave a Comment

Please sign in to add a comment. Not a member? Join today