I don’t know about the requirements for encryption, but the standard way to see the results on the wire would be to use Wireshark. It should be obvious when encryption is enabled as you will no longer be able to see the payload as plain text.
You’re going down a dangerous path, since, frankly, you seem uninformed about a lot of the specifics of the technologies involved here.
To answer your specific questions:
Yes, but this could be misleading. JSON is just a way to organize a plain-text payload, and doesn’t imply anything about encryption.
Installing an SSL certificate on the Ignition gateway will do absolutely nothing for any calls to an external REST API. You need to have a certificate for that server (and enable whatever features on the server necessary to ‘upgrade’ requests to HTTPS) to ensure communication from clients (such as scripting methods in Ignition) must be encrypted.
Local clients that can talk to arbitrary webservers abound. E.G:
Powershell has a cmdlet for talking to REST APIs:
Or if you’re on a *nix system, you’re basically guaranteed to have curl installed.
SSL certificate on Ignition ensures secure communication as long as Ignition is working as server (like communication between clients and Ignition gateway or Ignition as web server).
system.net.httpPost() with https url endpoint (to be provided by server where data will be sent to) will ensure encryption. (Someone with similar limited knowledge about API calls as me asked if httpPost function can call https url. Though I thought it can, I did not have definite answer, so just wanted to confirm)
I will try one of the above options for testing API call.
Yes, that’s essentially correct. Note that Ignition has a specific toggle to require HTTPS - if not enabled, then both encrypted and unencrypted sessions are allowed. You can also opt-in to HSTS (Http Strict Transport Security) by setting a gateway configuration flag; briefly, HSTS lets clients know to ‘cache’ the HTTPS requirement and never allow HTTP connections for some duration.
Yes, as long as you’re connecting to an HTTPS URL, the protocol will dictate/require encryption to connect. Note that encryption does not mean security, intrinsically - you can generate a ‘self-signed’ certificate, and still send perfectly valid HTTPS traffic over it. Such a self signed certificate can be compromised or duplicated such that a ‘bad actor’ could still capture your encrypted traffic in-transit over the network and decrypt it.