Description
When accessing the web console, the header loads, but the login prompt never shows up, instead it's only a white blank screen forever.
This issue is different than the one that happens when the public URL is not configured in the Security->Advanced->CSP setting.
This issue would normally be seen after configuring the SSL certificate for accessing the web console with FQDN.
Cause of the issue
One of the causes identified was that the inconsistent letter case used for the FQDN defined in the SSL certificate and configured for the publicUrl option in the server configurations.
Steps to check
1) Certificate and Public URL
First check the domain defined in the SSL certificate. Below example shows that the FQDN "myserver.com" with all lower case is defined in the SSL certificate added to the STS 10 server:
Check the Public URLs configured in the console's setting and make sure it exactly matches the FQDN (myserver.com in all lower case) defined in the certificate above.
| When using 443 https port | If using default application 3449 ports |
2) Frame CSP
Check the console address configured in the CSP settings and make sure it is using exactly the same FQDN as well:
| When using 443 https port | If using default application 3449 ports |
In case you cannot connect to the Web UI:
mongo -u systranAdmin -p SESpasswordAdmin --authenticationDatabase admin
use settings
db.settings.update({},{$set:{"settings.Security.Advanced.Csp.frameAncestors" : ["https://hostname:3449"]}})
db.settings.update({},{$set:{"settings.Security.Advanced.Csp.frameSrc" : ["https://hostname:3449"]}})
systemctl restart systran-ses-console
Adjust URL and port according to your installation.
Note:
You can wildcard frameSrc and frameAncestors using https://*
☠️ This is a bad security practice
3) PublicURL and Frame CSP
Check the FQDN configured for the publicUrl options in the <hostname>.yaml files for ses-frontend. Make sure they exactly match as well:
For the frontend:
| When using 443 https port | If using default application 3449 ports |
Restart the server.
Note:
It is not clear what would happen if the FQDN in the certificate was using all upper case or mixed case, and used throughout the server's settings. Probably it would be better just to advise the customers to unify it with all lower case from the beginning to avoid this potential issue.