HTTP_CONFIG  Index, Config_string (only available on Wx PLC firmware >= F94.4)
Purpose To config the HTTP parameters that enables the PLC to connect to the remote web broker(server)
 
Index DescriptionDefault Config_stringLimit
1
Use Secure (TLS) Connection"0"  - non-secured connection "0" or "1"
2
Username""Max. 32 ascii characters
3
Password""Max. 32 ascii characters
4
Enable CNname Check"0""0" or "1"
5
Enable CA cert check"0""0" or "1"
6
Server CA Cert Filename""  - not used"Max. 32 ascii characters
7
Client (i.e. PLC) cert filename""  - not used Max. 32 ascii characters
8
Client (i.e. PLC) private key filename""  -not used Max. 32 ascii characters
9
Client (i.e. PLC) private key password""  -not used Max. 32 ascii characters
10
Keep connection open"0" "0" or "1"
Examples
	
	HTTP_CONFIG 2, "MyName"       ' username needed to connect to a folder on a HTTP/HTTPS server. 
	HTTP_CONFIG 3, "MyPassword"   ' password needed to connect to a folder on a HTTP/HTTPS server. 
Demo programs: C:\TRiLOGI\TL75\usr\samples\Wx_Specifics\HTTPS_Examples.PC7 and HTTP (non_TLS)Examples.PC7
Comments:
  1. With this command you can define all the parameters necessary for the PLC to successfuly connect to the HTTP or HTTPS web server.
  2. Not all indices are needed. E.g. if you are not using secure connection, then you do not need to define the certs and key filenames (index = 4 to 9)
  3. If the PLC is to use encrypted (TLS) connection to connect to the server, then configure it to Use Secure (TLS) Connection as follow:
       	 HTTP_CONFIG 1, "1"	
    Note: the above command is only effective if the URL_string in the HTTP_COMMAND does not include a "http://" or "https://" prefix. Otherwise this setting is ignored and the prefix will determine the connection security type.

  4. TLS (encrypted) Connection Explain

  5. TLS connection involves the client (PLC) and the web server exchanging encryption keys during the initial connection (handshake) and it is a complex and time consuming process (typically takes a few seconds to complete). Once the keys exchanges are completed the client and server agree on a secret key that are used to encrypt all data exchanges between the two parties. The connection is now considered "secured".

    For applications that require highest security (such as banking transactions), the client will also want to make sure that the server that it is connecting to is the "real" thing. This requires a 3rd party, trusted entity to certify that the server is "real" and this 3rd party entity is known as the "Certification Authority (CA)". The CA issues a CA certificate that is used to "sign" the server's own encryption keys (expressed as digital certificates). When the client initiates connection with the server it uses the CA certificate to check against the server certificate to make sure that it is valid. We call this process "CA cert check".

    To enable Wx PLC to carry out "CA cert check", first you must download the valid CA cert PEM file from the web server and store the PEM file in the PLC's local disk space. You will then need to run the HTTP_CONFIG 5,"1" command and also run HTTP_CONFIG 6, [CA cert PEM filename string]. You probably should also run the HTTP_CONFIG 4,"1" command to enable the CNname check to maximize security. (The only reason you want to turn off CNname check while turning on CA cert check is when the server does not have a domain name but only an IP address and thus there is no valid CNname to check).

    Caution: Note that all CA certicates have expiry date (can be from a few months to a few years) and once the certificate has expired the communication with the server will fail. This means that if you are enabling CA cert check you will need to properly schedule maintenance to update the CA cert before expiry to prevent sudden loss of communication.

    In our opinion, unless the PLC is connected to a public WiFi where some man-in-the-middle attacker can put up a "DNS Spoofer" to redirect your web server connection to bogus website, it may not be necessary to enable the CA cert check since most PLCs are likely connected to a work place or home network and has no danger of meeting a DNS spoofer.

    By not enabling CA cert check it eliminates the necessity to find, store and maintain the CA cert on the PLC file space. With or without the CA cert check the TLS data exchanges between the PLC client and the web server on the Internet are still encrypted and are thus secured against eave-dropping.
  6. If you are simulating the TLS communication with CA cert check using i-TRiLOGI simulator, the certificates and key files should be copied to the folder C:\TRiLOGI\certs\
  7. Some web servers only allow selected clients to connect to it. It typically does it in two ways:

    1. The most common way is to authenticate via username+password and this can be used for both encryted (TLS) and non-encrypted connection. During initial connection the server requests the client to supply the valid username and password and only authenticated clients are allowed in. You must run the HTTP_CONFIG 2, [username string] and HTTP_CONFIG 3, [password string] before running the HTTP_COMMAND so that the PLC will be able to supply the credentials when queried by the server
    2. The second method is only applicable to TLS encrypted connection, where the server will require the client to supply a client certificate that has been signed by a CA that it recognizes. The client certificate lets the server know that you are really who you said you are and it can then check your identity against a database of authenticated users before granting you access. It will be rare for a PLC to be issued client certificates for communicating with web server. But if required the PLC must run HTTP_CONFIG with index 7,8 and 9 to define the client certificate, client's private key file and password to the private key file before running HTTP_COMMAND.

      Note:
      The client certificate feature is currently experimental and not officially supported, but we welcome feedback from users who have actually tried using it.
  8. Keep Connection Open: After a HTTP request has been sent to a webserver and a proper response has been received by the client the connection is usually closed automatically either by the client (PLC) or the server after a short time-out period. However, if you have a few HTTP requests that you would like to send to the same web server (same server host address) consecutively, then it is more efficient to use the same connection to send multiple HTTP requests. The efficiency improvement is especially significant for encrypted (TLS) communication than non encrypted communication since the initial handshake of a TLS connection session can take several seconds. To keep the connection open, run the command HTTP_CONFIG 10, "1" before the HTTP_COMMAND. Please remember to run HTTP_CONFIG 10, "0" before the last HTTP_COMMAND to allow the connection to close after running the last HTTP_COMMAND in a custom function.

 

See Also HTTP_COMMAND, HTTP_STATUS(n), HTTP_POST_BUF, HTTP_INPUT$(1)

backbutton.gif (507 bytes)  Basic to TBASIC Reference Manual