[bug-15073]Perspective view editor won't open

Ignition Early Access
1

Hi, Guys

I’m trying to create the first view in a Perspective project. This is what I get

This site can’t be reached

PerspectiveEditor
PerspectiveEditor2080×1560 1 MB

Ignition platfofrm 8.0.7 - Activated
Perspective module 1.0.7 - Activated, Running

Please help

2

Note the very last line of the error:

ERR_CERT_AUTHORITY_INVALID

If you are going to use SSL and a self-signed certificate, you have to tell Chrome to trust it. Or not do that. /:

3 Likes
3

Thank you. I disabled SSL in WebServer for now. That helped

4

I had to enable SSL. The editor doesn’t work anymore.

I’m using self-signed Ignition certificate. I configured the gateway according to the manual. Design launcher has no issued fining the https:// gateway, the project opens fine. I imported the certificate to Chrome. Perspective session opens fine in Chrome.

But the editor doesn’t work.

How can I fix this?

5

The embedded web browser frame doesn’t use Java’s keystore - it uses the OSes. Since you’re using a self-signed certificate, you have to trust your certificate in the operating system’s trust store, at which point the embedded browser engine will recognize it.

This is an issue we’re aware of and plan to fix, but that’s the workaround for now.

2 Likes
6

Thank you.
How do I trust the certificate in Windows?

7

Looks like there’s a built in cert management tool: https://www.thewindowsclub.com/manage-trusted-root-certificates-windows

1 Like
8

The Windows solution works for our self-signed certificate. Designer can edit views.
But am having trouble with designer running on OpenSuse 15.1 (and Ubuntu). The view editor will not open the perspective view for editing. says “ERR_CERT_INVALID”
I’ve added the certificate to the /etc/ssl/certs/ directory (Suse) and performed sudo update-ca-certificates but with no success as to editing views in the designer.
The cert I added was exported from the browser from our gateway designer-launchers page as a .crt file instead of a .pem file. Everything else in /etc/ssl/certs is a .pem file.
Anyone else have success in Suse or Ubuntu?

9

Has there been any update to this issue? Specifically on Linux?
Just as @jcoleman did, I added my certificate to the OS certificate store. I’ve restarted Designer but I’m still getting the same error. I’ve confirmed with the openssl tool that a connection from my system works and the certificate is validated.

To elaborate on @jcoleman’s comments:

  • update-ca-certificates should show that it added a certificate. Initially it did not for me. Once I renamed my certificate from *.pem to *.crt, it worked and showed “1 added”.
  • I did not add my certificate directly to /etc/ssl/certs/ but rather to /usr/local/share/ca-certificates/ as it appears that is where update-ca-certificates looks.
  • Once the certificate was added, I tested with the following:
    • openssl s_client -connect <server url here>:443 -CApath /etc/ssl/certs
    • You should see the “Verify return code” equal to 0 (ok) as opposed to 18 (self signed certificate)

@PGriffith, do you have any ideas?

10

Does it show as trusted in Chromium? I don’t know the exact path Chromium (and therefore JxBrowser) use on Linux to build trust.
Either way, I’ve bumped the internal ticket’s priority so we can see about fixing this first party.

11

Chrome does not work either. I thought it was using it’s own cert store but that is not true (yet). So this helped me find that it uses a different store as described here: https://chromium.googlesource.com/chromium/src.git/+/master/docs/linux/cert_management.md
After adding the cert to the NSS DB, I now get a new error, ERR_CERT_COMMON_NAME_INVALID.
The CN value and my server name match exactly so I don’t know what is wrong here. I’ll keep looking but I’m curious if other have luck with this process and their certs.

I tested the certificate in Firefox and it complains because the certificate CA is the same server.

I’m trying to confirm that the certificate, generated from the Ignition configuration interface, will work in any case. I can use Designer when running on the server that hosts the Ignition Gateway. I can launch a project in a browser by ignoring the certificate warnings. I cannot however get the iOS app to trust the certificate. The profile is installed and the certificate is trusted. The app keeps saying the certificate must be installed even after forcing it closed and restarting.

12

Does your self-signed certificate have a SAN with a DNS entry that matches the server’s FQDN?

2 Likes
13

@Kevin.Herron, that was indeed the issue. I believe everything is working now on Linux and iOS.

To recap for Linux users:

  • When generating the self-signed certificate in Ignition, under “Subject Alternative Names” enter your DNS name. Click “Add” or the name will not be part of the certificate.
    • This appears to be necessary for all versions of Designer and the iOS app.
  • Use Chrome to navigate from the Linux workstation to the Ignition Gateway and export the certificate it presents.
  • Use Chrome’s certificate manager (at chrome://settings/certificates) to import the certificate under “Authorities”.
    • Again there are other ways to do this.
    • The common trusted CA list at /etc/ssl/certs/ca-certificates.crt is not applicable here.
1 Like
15

8.1.24, still not fixed? Is there a workaround?

16

What's not fixed? The last issue discussed here was a problem with the certificate missing a SAN entry.

1 Like
17

I'm having trouble getting the Perspective Designer pages to load with self-signed cert. Importing into Window's keystore doesn't seem to help either. Was hoping to find out if a simpler fix has been made, like having the designer accept the cert if the designer client was set to trust it. Or a setting in the designer somewhere. Thanks for responding!

18

The original fix mentioned here was done, but if there's something wrong with the structure of your certificate like the previous post then it still won't work.

Can you upload it here so we can take a look?

19

Kevin,

Thank's for hinting I should look harder and offering to help... I realized the issue was the missing SAN (Subject Alt Name). I had incorrectly assumed the CN (Common Name) matching the hostname would be sufficient. Re-creating it with CN set to the hostname AND adding a SAN for each the IP and the hostname fixed this.

1 Like