I have iis 10.0 which host two domains ssl cert, say 1 is www.abc.com and the another is www.dfg.com, both domain are pointing to the same iis. So I can access webpage like https://www.rgx.com/calculation.aspx and
https://www.dfg.com/calculation.aspx both. The problem is that for most page, both domain work properply, but for some webpage in one domain e.g dfg.com https://www.dfg.com/questions.aspx, it cannot be loaded, in firefox, it returns
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.
So what is the reason that some page cannot be accessed in one domain but can in another domain?
Do you have an error code? This error seems to only appear in Firefox, try the following in Firefox to see if it resolves the issue on your end:
Open about:preferences#privacy in the browser.
Scroll down to the Certificates section and click on "View certificates".
Make sure the Authorities tab is selected.
Locate Avast certificates and use the delete option to remove them.
Use the import button to import the certificates from C:\ProgramData\AVAST Software\Avast\wscert.dat.
Related
I have the following scenario. I have a website in IIS 8 and I am trying to secure it (https). I have made the web with web forms. In the process to secure it I have to change the page at the beginning (default page in the IIS administrator). When I do it, I don't get the change and I go to the website that was set by default.
I have seen the log and when trying to access the new homepage it gives an error 302 (object moved). I have seen the response header and I see that the location is configured with the old home page.
Example:
Old default page: www.namedomain.com/start.aspx
New default page: www. namedomain.com/home.aspx
The new website has as in the response header: location = /start.aspx and as I said before when trying to access it gives error 302.
Thanks.
There's a few things going on here, "securing" the site with HTTPS and also potentially <authentication mode="Forms"> in your web.config where it will try and redirect any unauthorised requests to a login page. It seems like you are just doing the HTTPS though at this stage, and maybe trying to set up a redirect from HTTP to HTTPS?
It sounds like you are also trying to change the default page for the website (in IIS or the web.config?) from default.aspx to home.aspx? I'm not sure I understand why you want to do that as it isn't necessary for HTTPS, but the effect of that will mean you can go to https://www.namedomain.com/ and you will get served the content from home.aspx instead of start.aspx (or default.aspx) but the URL will stay as just https://www.namedomain.com/
Normally to set up HTTPS, all you do is go into IIS, Bindings, and add a HTTPS binding (you'll need a TLS certificate to make the https work properly). then just make sure you include the "https://" at the start of your URL.
If you think it might be caching problem on your machine, just add a nonsense querystring to the end of your URL (like https://www.namedomain.com?blah=blahblah) and it will cause your browser to get a fresh copy of the page.
I'm not sure what is causing the 302 redirect, have you added any special code to swap HTTP requests over to HTTPS? Can you update your answer with any more info?
Yes, it is what I put in my last comment Jalpa. I do not understand very well the relationship between not configuring the session variables and the default page but once corrected in code, the application correctly loads the web by default.
I have been trying to enable HTTPS login on alfresco but it seems to be a challenge to get it working.
I can access my website via HTTPS and get the login page, but when I login with the correct credentials I get the following error :
Something's wrong with this page...
We may have hit an error or something might have been removed or deleted, so check that the URL is correct.
Alternatively you might not have permission to view the page (it could be on a private site) or there could have been an internal error. Try checking with your IT team.
If you're trying to get to your home page and it's no longer available you should change it by clicking your name on the toolbar.
I must login in HTTP then refresh my HTTPS page to be connected in HTTPS.
I have already seen what the offical doc says and tested it but it didn't work.
Has anyone an idea on how to fix the problem ?
Thanks
The alfresco.log / catalina.out should tell your more.
Where / how did you set up https? Have a a reverse proxy like nginx or apache in front of the alfresco tomcat?
If the log says something like "CSRF Token Filter issue" then you need to set share.host / port / protocol in alfresco-global.properties as seen from the browser.
we have an odd situation where a user logs into the site (Asp.Net), and upon logging out, it only directs us to the main page "https://newsite/default.aspx" however if we replace default with login, we are immediately logged back in. This happens only when we go through the public IP with associated DNS A record located on the F5. If we open the site on the IIS server via IP binding "https://ipaddress/default", I can login and logout and stay logged out, it works as expected. I have worked with F5 support and have tried multiple different configuration changes, and no dice, same behavior everytime. The newsite is set up identically in F5 to our current production site, and developers say the logout code is identical to current production so we are confused as to why this is happening. Persistence is set on the load balancer as well. Any help in the right direction would awesome.
A couple things I would suggest checking:
If you monitor the traffic with something like Fiddler and compare the results of login/logout with the F5 and without, do you see any difference? I would look for specific things like cookies being set or removed. I know ASP.NET uses specific cookies for sessions, so I would wonder if that cookie is not getting deleted properly on logout.
Once you log out of the site (when going through the F5), if you refresh the page, do you stay logged in (in this case, I could see where some kind of caching may send back the page even though you're logged out. If this is the case, you could have an F5 admin check to see if there's a Web Acceleration profile on the virtual server and remove it to see if that helps.
Looks like specific security cookie code was causing the issue of creating a duplicate cookie within ektron.
Following code was removed, and now log out is working properly via SSL through our F5.
Code removed:
Dim lSec As SecurityAPI.Cookie = New SecurityAPI.Cookie(Me, mServerEnvironment, mCOGUser.PeopleID)
lSec.SetCookie()
I have a site hosted in IIS 6.0 (I've also tested it with IIS 7.0, same result) and I've configured my page so that it only accepts iframes hosted in the same origin domain using this: http://support.microsoft.com/kb/2694329
I have added the "X-Frame-Options" field name and "SAMEORIGIN" value in the HTTP Headers tab in IIS.
That means "The page can only be displayed in a frame on the same origin as the page itself."
Now my pages can't be hosted in any other website/domain which is fine and expected.
The problem is that I have an https page whose parent is an http page both of which within the same domain. I expected this to work but I get the bellow error:
This content cannot be displayed in a frame
To help protect the security of information you enter into this website, the publisher of this content does not allow it to be displayed in a frame.
What you can try:
Open this content in a new window
How to configure my site or what HTTP Header to add to allow an https page being iframed within an http page?
I also tried using "ALLOW-FROM" header name and adding specifically my domain names:
"http://mydomain.com" and "https://mydomain.com"
but it said
"The custom header already exists in the list".
So does "Origin" refer to both the domain and protocol? if so that seems to be a design issue? Or is there any workaround?
Thanks,
We've recently run into an issue with our ASP.NET application where if a user goes to ourcompany.com instead of www.ourcompany.com, they will sometimes end up on a page that does not load data from the database. The issue seems to be related to our SSL certificate, but I've been tasked to investigate a way on the code side to fix this.
Here's the specific use case:
There is a user registration page that new users get sent to after they "quick register" (enter name, email, phone). With "www" in the URL (e.g. "www.ourcompany.com") it works fine, they can proceed as normal. However, if they browsed to just "ourcompany.com" or had that bookmarked, when they go to that page some data is not loaded (specifically a list of states from the DB) and, worse, if they try to submit the page they are kicked out entirely and sent back to the home page.
I will go in more detail if necessary but my question is simply if there is an application setting I can say to keep the session for the app regardless of if the URL has the "www" or not? Buying a second SSL cert isn't an option at this point unless there is no recourse, and I have to look at a way to solve this without another SSL.
Any ideas to point me in the right direction?
When your users go to www.ourcompany.com they get a session cookie for the www subdomain. By default, cookies are not shared across subdomains, which is why users going to ourcompany.com do not have access to their sessions.
There is a useful thread discussing this issue here. The suggested solution is:
By the way, I implemented a fairly good fix/hack today. Put this code
on every page: Response.Cookies["ASP.NET_SessionId"].Value =
Session.SessionID; Response.Cookies["ASP.NET_SessionId"].Domain =
".mydomain.com";
Those two lines of code rewrite the Session cookie so it's now
accessible across sub-domains.
Doug, 23 Aug 2005
Surely you are trying to solve the wrong problem?
Is it possible for you to just implement URL rewriting and make it consistent?
So for example, http://example.com redirects to http://www.example.com ?
For an example of managing rewriting see:
http://paulstack.co.uk/blog/post/iis-rewrite-tool-the-pain-of-a-simple-rule-change.aspx
From the browsers point of view, www.mysite.com is a different site than mysite.com.
If you have a rewrite engine, add a rule to send all requests to www that don't already have it.
Or (this is what I did) add a separate IIS site with the "mysite.com" host header and set the IIS flag to redirect all traffic to www.
In either of these cases, any time a browser requests a page without the www prefix, it will receive a redirect response sending it to the correct page.
Here's the redirect site home directory properties:
And the relevant host header setting:
This fixes the issue without requiring code changes, and incidentally prevents duplicate search results from Google etc.
Just an update, I was able to fix the problem with a web.config entry:
<httpCookies domain=".mycompany.com" />
After adding that, the problem went away.