Setting up HTTPS for your SCADA system is often a requirement for modern industrial systems, especially when remote access is involved.
In this guide, you will learn how to create and integrate the necessary certificate files and configurations in order to secure https web access in atvise SCADA 3.11, step-by-step.
Requirements
To complete this procedure, make sure you have the following:
- Access to the configuration panel of your domain
- Access to your router or network device configuration panel (Port-forwarding - Firewall rules)
- atvise SCADA 3.11
- ACME Client (Automated Certificate Management Environment). Recommended: win-acme version 2.2.9.1701
1. CDN configuration
Once we login into the CDN (Content Delivery Network), you will find your configured domains. Go to the desired domain configuration panel and find the section for DNS configuration. In this tab, you will create the correct DNS record for your environment.
You must complete the required fields, which vary per record and network architecture.
Common DNS record parameters:
- Record type: A.
- Name: desired name of the subdomain (or root domain)
- Content: the destination IP (for any user to access through our domain, use public IP)
- Proxy status: You can often configure the proxy status for IP related records. By activating the proxy, users will pass through the CDN before accessing our system. It can be activated for increased security. If the proxy is disabled, the CDN will handle the DNS directly with your IP.
2. Network configurations
Once your domain points to your public IP, you need to ensure that traffic is properly routed to your SCADA server:
Port Forwarding
Log in to your router’s configuration interface, go to the security or single port-forwarding tab and:
- Create a redirection of the desired external https port (https port that users will use to access) to the internal https port (https port for atvise server) on your machine IP. In this example, I used the 8443 internal and external port with the device IP of my machine where atvise server is running.
Firewall Rules (if needed)
- Allow inbound TCP connections on atvise https port to reach the SCADA server.
- Optional: Limit external access to specific IP ranges for increased security.
Note: For some certificate authorities like Let's Ecrypt, you might need to open port 80 or port 443 too in your device IP for certificate renewal features or API validations.
3. Certificate files generation
Now that we have configurated our DNS and network rules, we can proceed with the generation of the necessary files. In this step, we will use an ACME client: win-acme 2.2.9.1701. After ownership of the domain(s) has been proven, win-acme will create a Certificate Signing Request (CSR) to obtain the actual certificate. The CSR determines properties of the certificate like which (type of) key to use. In this example we will use the Eliptic Curve Key.
The certificate files will be generated by the ACME client by validating that we own the domain via Let's Encrypt API, and the result will create a TLS X.509 v3 domain validation certificate (DV) issued by Let’s Encrypt with the respective .pem and .der files.
So, once you downloaded win-acme, you need to extract the .zip in your hard drive disk. When you extract it, go to the win-acme folder and run wacs.exe with administrator privileges. This will open a console, where we will follow the instructions to generate the correct files.
For this step, remember we are not using Windows IIS certificate store nor bindings, so you must avoid options related to this topic.
Step-by-step win-acme:
A simple Windows ACMEv2 client (WACS)
Software version 2.2.9.1701 (release, trimmed, standalone, 64-bit)
Connecting to https://acme-v02.api.letsencrypt.org/...
Connection OK!
Scheduled task looks healthy
Please report issues at https://github.com/win-acme/win-acme
N: Create certificate (default settings)
M: Create certificate (full options)
R: Run renewals (0 currently due)
A: Manage renewals (1 total)
O: More options...
Q: Quit
Please choose from the menu: M
Running in mode: Interactive, Advanced
Please specify how the list of domain names that will be included in the
certificate should be determined. If you choose for one of the "all bindings"
options, the list will automatically be updated for future renewals to
reflect the bindings at that time.
1: Read bindings from IIS
2: Manual input
3: CSR created by another program
C: Abort
How shall we determine the domain(s) to include in the certificate?: 2
Description: A host name to get a certificate for. This may be a
comma-separated list.
Host: test.vesterbusiness.com
Source generated using plugin Manual: test.vesterbusiness.com
Friendly name '[Manual] test.vesterbusiness.com'. <Enter> to accept or type desired name: atserver@test.vesterbusiness.com
By default your source identifiers are covered by a single certificate. But
if you want to avoid the 100 domain limit, want to prevent information
disclosure via the SAN list, and/or reduce the operational impact of a single
validation failure, you may choose to convert one source into multiple
certificates, using different strategies.
1: Separate certificate for each domain (e.g. *.example.com)
2: Separate certificate for each host (e.g. sub.example.com)
3: Separate certificate for each IIS site
4: Single certificate
C: Abort
Would you like to split this source into multiple certificates?: 4
The ACME server will need to verify that you are the owner of the domain
names that you are requesting the certificate for. This happens both during
initial setup *and* for every future renewal. There are two main methods of
doing so: answering specific http requests (http-01) or create specific dns
records (dns-01). For wildcard identifiers the latter is the only option.
Various additional plugins are available from
https://github.com/win-acme/win-acme/.
1: [http] Save verification files on (network) path
2: [http] Serve verification files from memory
3: [http] Upload verification files via FTP(S)
4: [http] Upload verification files via SSH-FTP
5: [http] Upload verification files via WebDav
6: [dns] Create verification records manually (auto-renew not possible)
7: [dns] Create verification records with acme-dns (https://github.com/joohoi/acme-dns)
8: [dns] Create verification records with your own script
9: [tls-alpn] Answer TLS verification request from win-acme
C: Abort
How would you like prove ownership for the domain(s)?: 1
Description: Root path of the site that will serve the HTTP validation
requests.
Path: C:\Users\Vester\Desktop\my-atvise-project-folder
Description: Copy default web.config to the .well-known directory.
Default: False
Argument: False (press <Enter> to use this)
Copy default web.config before validation? (y/n*) - no
After ownership of the domain(s) has been proven, we will create a
Certificate Signing Request (CSR) to obtain the actual certificate. The CSR
determines properties of the certificate like which (type of) key to use. If
you are not sure what to pick here, RSA is the safe default.
1: Elliptic Curve key
2: RSA key
C: Abort
What kind of private key should be used for the certificate?: 1
When we have the certificate, you can store in one or more ways to make it
accessible to your applications. The Windows Certificate Store is the default
location for IIS (unless you are managing a cluster of them).
1: IIS Central Certificate Store (.pfx per host)
2: PEM encoded files (Apache, nginx, etc.)
3: PFX archive
4: Windows Certificate Store (Local Computer)
5: No (additional) store steps
How would you like to store the certificate?: 2
Description: .pem files are exported to this folder.
File path: C:\Users\Vester\Desktop\Certificates
Description: Password to set for the private key .pem file.
1: None
2: Type/paste in console
3: Search in vault
Choose from the menu: 1
1: IIS Central Certificate Store (.pfx per host)
2: PEM encoded files (Apache, nginx, etc.)
3: PFX archive
4: Windows Certificate Store (Local Computer)
5: No (additional) store steps
Would you like to store it in another way too?: 5
Installation plugin IIS not available: Requires CertificateStore or CentralSsl store plugin.
With the certificate saved to the store(s) of your choice, you may choose one
or more steps to update your applications, e.g. to configure the new
thumbprint, or to update bindings.
1: Create or update bindings in IIS
2: Start external script or program
3: No (additional) installation steps
Which installation step should run first?: 3
Plugin Manual generated source sebastest.vesterbusiness.com with 1 identifiers
Plugin Single created 1 order
Downloading certificate atserver@sebastest.vesterbusiness.com
Store with PemFiles...
Exporting .pem files to C:\Users\Vester\Desktop\Certificates
Scheduled task looks healthy
Adding renewal for atserver@sebastest.vesterbusiness.com
Next renewal due after 2025/6/23
Certificate atserver@sebastest.vesterbusiness.com createdAfter this, you will find the corresponding PEM files in the directory that you prompted in the console. The files that we generated are:
mydomain.com-chain.pem
mydomain.com-chain-only.pem
mydomain.com-crt.pem
mydomain.com-key.pem
4. atvise Format Requirements
Once you validated the files were generated, we must adjust the format (X.509v3) in order to atvise to recognize correctly the certificate.
PEM files format in atvise certificate store
The atvise manual says:
Certificates from trustworthy certificate authorities can be used for every atvise application and must be stored in the appropriate certificate store and comply with the OPC UA standard.
Certificates issued by a certificate authority (CA) consist of a certificate chain – the actual end certificate for the application, intermediate certificates and a root certificate of the certificate authority. Each certificate in the chain is signed by the certificate above. The end certificate is trustworthy if it has a valid signature and the entire certificate chain is trusted. The certificates of the chain must be manually moved to the appropriate directories of the certificate store.
Certificates from a certificate authority must comply with the OPC UA standard and include the required information. Therefore, it may be necessary to issue existing certificates again. If an existing certificate is invalid or no self-signed certificate can be created during application startup, the application will fail to start.
In case of HTTPS, only a PEM file can be selected because the file must contain the certificate (or the certificate chain) and the private key.
FQDN
FQDN (Fully Qualified Domain Name) must match the Common Name / SAN of the certificate (mydomain.com).
What this means is that atvise requires a single .pem file containing:
- End certificate for the application (or leaf)
- The intermediate certificate
- The private key
So, the next step is to unify the different files we have into one file, the certificate chain.
Go ahead and open CMD as Administrator and go to the directory where the certificate files are using cd and execute the following command to unifiy the different parts of the certificate:
C:\Users\Vester\Desktop\Certificates>type mydomain.com-chain.pem mydomain.com-key.pem > cert_https.pem
After this, you will find a new file called cert_https.pem. This is the unified certificate file ready for atvise interpretation. You can validate that the new file has this format.
----- BEGIN CERTIFICATE --- ← LEAF
----- END CERTIFICATE --------
----- BEGIN CERTIFICATE --- ← INTERMEDIATE
----- END CERTIFICATE --------
----- BEGIN PRIVATE KEY -------- ← PRIVATE KEY
-----END PRIVATE KEY --------
Now, we need to locate the atvise server certificate store, which you can find in the atvise builder navigation tree: My Server, Web Server, https1, edit Web Server...
Follow that directory and paste the new unified file in there.
Important: You must rename the file to your domain name. If the name does not match with the domain name, the web browser will show an error.
5. Final Steps
Now that we have the correct files, we just need to configure the atvise server based on the rules that we prepared.
- Configure your correct https port in atvise Project Console
- Run your server.
- Set up the https web server connecting to the builder. For this, configure the IP address of your machine, and select the unified .pem file we added before, located in the /https directory
Congratulations! You secured your web server.
FAQ:
What certificate types can be used in atvise?
atvise uses X.509v3 certificates (according to the OPC UA standard), which must be stored as DER files in the respective certificate store. The corresponding private keys must be stored as PEM files. The following certificate types can be used:
Client certificates – Authenticate the client (e.g. atvise builder) to the server (e.g. atvise server) and ensure a secure connection.
Server certificates – Authenticate the server to the client and ensure a secure connection.
User certificates – Enable the login to OPC UA servers (e.g. atvise server) without username and password.
HTTPS certificates – Enable a secure communication with web servers. In this case, no client-side certificates are required – the client uses the web server's certificate (which also contains the private key) to verify if it is trustworthy.
Is this a self-signed certificate or is it a trusted authority certificate?
Since we are validating that we own the domain using win-acme and Let's Encrypt's API, we are not using a self-signed certificate.
For further questions,
Contact: s.garro@vestersl.com
Create a technical support ticket: soporte@vestersl.com
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article