We have configured openHistorian web application in https mode (using self-signed certificate).
I have created user “A” – database user not an AD user.
Login process is not working for “user A” and keep holding status “Attempting authentication”.
Do we need to do any configuration to work in https mode?
Note that, in normal https mode “user A” login process is working fine.
Thanks & Regards
I suspect the certificate is failing to be verified. When using a “self-signed” certificate - the certificate must be installed on all machines that intend to “trust” the host certificate.
In order to create a more globally trusted certificate, you will need to generate the certificate using a certificate authority (CA) registered on your machine as “trusted”. This can be generated by a company level CA, or one one of the more commonly trusted ones on the Internet (assuming your machine has access to the Internet).
Check the image, there is no error, even this status is for whole night.
Self-signed certificate has been installed in all client machine and I’m able to access the login page without any error. Also this self-signed certificate was created using openSSL APIs.
Additionally, I created self-signed certificate using IIS Manager and configured it. I’m able to load the login page, but still same issue, see the below image. Also there is no error in browser.
In fiddler, I could not see any transaction between browser and server and not seeing.
If you have any suggestion, please let me know, meantime, I will check the certificate.
I’ll see if I can replicate.
Actually, I’m facing this issue in openHistorian 2.6.
Whereas, I did not see this issue in openHistorian 2.7.
Is there any fix for SSL and basic authentication. Also I found one observation.
Installed openHistorian 2.6
Created database user A - Not AD user.
I’m able to successfully authenticated using normal http mode
Configured SSL mode using self-signed certificate
I’m not able to authenticate or login through database user in https mode
Reverted to normal http mode
Even changed to http mode, I’m not able to login using basic authentication.
Finally, I uninstalled openHistorian 2.6 and reinstalled
Again from step 2 is continues.
Is there any configuration settings missed in older version?
Thanks & Regards
Currently, I’m debugging openHistorian 2.6 source code and found the cause:
Login request is hanging at below code or location:
File Name: GSF.Web.Security.SessionHandler.cs
Here, line no 302 is hanging when assigning new credential object.
private string IssueAuthenticationToken(string username, string password)
credentialCache[selector] = new Credential
Validator = validator,
Username = username,
Password = password,
Expiration = DateTime.UtcNow.AddDays(30.0D)
- Configure openHistorian in SSL mode
- Access login page using https://localhost:8181 - > now login page is served
- Enter credential and getting status message at browser “Attempting Authentication”.
Actually, the above function and line 302, is hanging.
This scenario is working fine at openHistorian 2.7. So please clarify, is there any changes in code? or any configuration setting is required?
After deleting CredentialCache.bin, I’m able to successfully do login in https mode.
thanks & Regards
Yes, there were many changes between 2.6 and 2.7 in the GSF code-base.
There are very many updates required to make 2.6 operate with bug fixes that came in from 2.7, two full sets of GSF releases:
It will take some time to cherry-pick only fixes needed.
Thanks for you information:
After deleting CredentialCache.bin , I’m able to successfully do login in https mode.
Very good! Glad you have a work around.
Deleting CredentialCache.bin . Is there any side effects?
The only thing this file is used for is to cache a user’s login token from the web page (the checkbox that says “keep me signed in”).
Removing the file simply requires users sign in again - so the operation is very safe.
Thank you very much ritchie.
One thing to note is that most of these cache files (e.g., the files that end with
.bin) are protected (i.e., encrypted) to the local machine. That means these files cannot be safely copied or used between two machines - they will only work on the machine on which they were created.
If you accidentally copied one of these files from another machine, it may give some trouble.