Wednesday 18 November 2020

HTTPS reset CALL with two servers

 Suppose server A(client) wants to make REST API call via SSL to server B

1) Server B needs to allow CORS(I.E allowing making requests from non origin domain and port)

2) Server A and Server B must complete the process of mutual authentication after TCP handshake.

3) Mutual authentication is Server A needs to present its server SSL to server B, and serverB needs to present its server SSL certificate to server A. Both server validate using open ssl / CURL then if its valid, server A(client) can create a symmetric key and use server B public key to encrypt, and then start communication 

4) One example would be serviceNow making REST API CALL to ansible tower via SSL.

ServviceNow requires an upload of Ansible tower server SSL certificate to cert store, then validate it when making https initial request with ansible tower. If two certs matched, service now then validates the certificate via open ssl. (Ansible tower in this case does not require servicenow certificate). When all valid, data are ecnrypted using symmetric key created from ServiceNow, and ecnrypted using public key from Ansible tower server SSL certificate.

https://docs.servicenow.com/bundle/paris-platform-administration/page/administer/general/task/t_UploadATrustedServerCertificate.html

https://hi.service-now.com/kb_view.do?sysparm_article=KB0696599

https://learn.akamai.com/en-us/webhelp/iot/internet-of-things-over-the-air-user-guide/GUID-21EC6B74-28C8-4CE1-980E-D5EE57AD9653.html#:~:text=Mutual%20authentication%2C%20also%20known%20as,certificates%20to%20prove%20their%20identities.


Mutual Authentication

Mutual authentication, also known as two-way authentication, is a security process in which entities authenticate each other before actual communication occurs. In a network environment, this requires that both the client and the server must provide digital certificates to prove their identities. In a mutual authentication process, a connection can occur only if the client and the server exchange, verify, and trust each other’s certificates. The certificate exchange occurs by means of the Transport Layer Security (TLS) protocol. The core of this process is to make sure that clients communicate with legitimate servers, and servers cooperate only with clients who attempt access for legitimate purposes.

The mutual authentication process involves the following certificates:

Root CA certificate
Used to identify a certificate authority (CA) that signed a client's certificate. It is a self-signed certificate that meets the X.509 standard, defining the format of public key certificates. In IoT products, clients upload a root CA certificate or a certificate chain to verify that the certificates that client devices send to edge servers can be trusted. See Upload the Mutual Authentication root certificate.
Server SSL certificate
Used to identify edge servers to client devices over TLS and to establish a secure connection during the TLS handshake. It is the enhanced TLS certificate that you provide in your property configuration. See Associate a property hostname to an edge hostname.
Client SSL certificate
Used to identify client devices to edge servers over TLS. This certificate must meet the X.509 standard, defining the format of public key certificates.
The process of authenticating and establishing an encrypted channel using certificate-based mutual authentication involves the following steps:


  1. During configuration, administrators provide a root CA certificate or a certificate chain used to sign certificates on client devices. They can do it in Certificate Provisioning System (CPS). See Upload the Mutual Authentication root certificate.
  2. The OTA Updates application deploys the certificate chain to the Akamai Platform.
  3. Once the signing CA certificates propagate across the Akamai Platform, client device can connect by using MQTT, HTTP, or WebSocket protocols and request access to a topic.
  4. The edge server presents its certificate to the client device.
  5. The client device checks its list of trusted CAs and verifies the server’s certificate.
  6. If successful, the client device sends its certificate to the edge server.
  7. The edge server checks its list of CAs and verifies the client device’s certificate.
  8. If successful, a secure connection between the server and the client device is established.

No comments:

Post a Comment