A Container's TLS Certificate
Every IDIAL container communicates over HTTPS only. For IDIAL-APP to trust a container safely, it validates that container's TLS server certificate against a fixed set of requirements. You see the result of this check in the container's TLS area — with an item-by-item breakdown of which check passed and which did not.
This guide explains what is checked, why, and what to do when a check fails.
What IDIAL-APP checks
The check runs in several steps. Each step produces its own result (passed, failed, warning, or not applicable). The overall verdict is only "trusted" when none of the active checks fail.
| Requirement | What is required | Why | If it fails |
|---|---|---|---|
| Trust chain | The certificate must trace back to a certificate authority (CA) you trust in the Trust Store. | Only then does the app know the certificate comes from an authority you recognise. | Add the issuing CA (or the root CA) to the Trust Store and mark it as trusted. |
| Validity | The certificate must be neither expired nor only valid in the future. | Expired certificates are considered insecure. | Issue a valid certificate. For "not yet valid", check the clock of the issuing system. |
| Intended use | The certificate must be marked for TLS server use (signature usage and "server authentication"). | Prevents, for example, a client-only or e-mail certificate from being misused as a server certificate. | Issue a server certificate with the correct intended uses. |
| Address (SAN) | The address you use to reach the container must be present in the certificate. If you connect via an IP address, that exact IP must be in the certificate. If you connect via a DNS name, that name must be in the certificate. | Ensures the certificate was really issued for this container. | Add the address you use as a "Subject Alternative Name" to the certificate — or connect via the address already in the certificate (and record it in the connection settings). |
| CA properties | Issuing CAs must be marked as a CA; the server certificate itself must not be a CA. | Prevents malformed certificate chains. | Have the chain issued correctly by your PKI. |
| Strength | No outdated algorithms (e.g. MD5/SHA-1) and no keys that are too short (RSA below 2048 bits). | Weak algorithms are considered insecure. | Re-issue the certificate with modern algorithms and a sufficient key length. |
| Revocation | If enabled: the certificate (and its chain) must not be revoked. | A revoked certificate must no longer be accepted. | See Revocation. |
In addition, the app checks whether the certificate presented on the wire matches the one the container reports. A mismatch is shown as a warning (a possible sign of misconfiguration) and does not block the connection.
Understanding the result
- Trusted (green): all checks passed. No further action is needed.
- Not trusted (red): at least one check failed. The app shows you which — with a reason. Based on that list you decide whether to fix the cause (e.g. add the CA, replace the certificate) or deliberately allow the connection anyway.
- Warning (yellow): a notice that does not block the connection (e.g. missing revocation information in "soft" mode).
Validate before uploading
Before you roll out a new server certificate to a container, you can have it validated in advance without installing it. You provide the certificate (as a PKCS#12 file with its password) and IDIAL-APP runs the same check as described above — and shows the result.
Use the pre-check to catch common pitfalls before rolling out — such as "the IP address you use is missing from the certificate" or "the issuing CA is not yet in the Trust Store". This prevents the connection from breaking after the upload.
Only once the pre-check is fine (or you deliberately choose "allow untrusted") do you roll out the certificate. After uploading, the IDIAL container must be restarted for the new certificate to take effect.
Deliberately allowing untrusted TLS
If a container certificate fails one of the checks but you still want to connect (typical in test environments or with freshly set-up containers that have a self-signed certificate), enable the Allow untrusted SSL option in the container's connection settings.
Allow untrusted SSL bypasses the check result and connects even with a non-trusted certificate. Use this option deliberately and preferably only temporarily. The clean long-term solution is almost always to fix the cause (add the CA to the Trust Store or issue a suitable certificate).
Revocation (CRL)
IDIAL-APP can check whether a certificate has been revoked in the meantime. How strictly missing revocation information is handled is something you set per container:
| Mode | Behaviour |
|---|---|
| soft (default) | Revocation is checked. If no current revocation information is available, the app connects anyway and shows a notice. |
| strict | Every link in the chain must have valid revocation information. If it is missing, the certificate is treated as not trusted. |
| off | No revocation check is performed. |
A certificate identified as revoked is always rejected, regardless of mode. Without a container-specific setting, the global default from the system settings applies.
In environments without continuous internet access (e.g. isolated plant networks), "soft" is often the right choice, because current revocation lists are not always reachable there.
Common cases and how to fix them
| Display / symptom | Likely cause | Fix |
|---|---|---|
| "Address not in certificate" | You connect via an IP/name that is not in the certificate. | Add the IP/name to the certificate, or connect via the address recorded in the certificate. |
| "Chain not trusted" / "CA missing" | The issuing CA or root is not in the Trust Store (as trusted). | Add the CA to the Trust Store and mark it trusted. |
| "Expired" / "Not yet valid" | The certificate's validity period does not match the current time. | Issue a valid certificate; for "not yet valid", check the system clock. |
| "No revocation information" (in strict mode) | No valid revocation list is available for a CA in the chain. | Provide a revocation list, or set this container's mode to "soft". |
| Connection is rejected as "not trusted" | A check fails and "Allow untrusted SSL" is off. | Fix the cause from the check list — or, if intentional, enable "Allow untrusted SSL". |
Related topics
- Trust Store — manage CA certificates centrally
- Add an IDIAL Container — register a new container in IDIAL-APP