We can activate secure connection for backends but as oppose to front-end we get this certificate warning: (is there a solution to no get this warning?)
This is probably not the site that you are looking for!
You attempted to reach backend.xxxx.appspot.com, but instead you actually reached a server identifying itself as *.appspot.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of requestprocessor.qminer-trial.appspot.com.
You cannot proceed because the website operator has requested heightened security for this domain.
Help me understand
When you connect to a secure website, the server hosting that site presents your browser with something called a "certificate" to verify its identity. This certificate contains identity information, such as the address of the website, which is verified by a third party trusted by your computer. By checking that the address in the certificate matches the address of the website, it is possible to verify that you are securely communicating with the website that you intended and not a third party (such as an attacker on your network).
In this case, the address listed in the certificate does not match the address of the website that your browser tried to go to. One possible reason for this is that your communications are being intercepted by an attacker who is presenting a certificate for a different website, which would cause a mismatch. Another possible reason is that the server is set up to return the same certificate for multiple websites, including the one you are attempting to visit, even though that certificate is not valid for all of those websites. Google Chrome can say for sure that you reached *.appspot.com, but cannot verify that that is the same site as requestprocessor.qminer-trial.appspot.com which you intended to reach. If you proceed, Chrome will not check for any further name mismatches.
This is a known issue: http://code.google.com/p/googleappengine/issues/detail?id=7288
It's a limitation of SSL and browser implementations: Wildcard subdomains on appengine over https on firefox
The workaround, as per docs, is to use -dot- in place of dots in your subdomain name: subdomain-dot-domain.appspot.com
This surely works for subdomains (tested), but I'm not sure if it works for backend domains. Please test it and let us know.
Update:
I tested this on one of my test backends (forgot it's still up) and it works as expected with the -dot- workaround.
Related
I have started developing a web app using React.js that serves as the front-end for a bigger project. Cutting to the chase, my issue is that I cannot find a way to communicate with a secure (https) API. This is running locally, and since my organization has self-signed certificates the browsers do not accept them. Namely, Chrome, Firefox, Edge, and Opera were used, with all of them resulting in more or less the same error: NET::ERR_CERT_COMMON_NAME_INVALID and Cross-Origin Request Blocked.
Some context regarding the followed process around the certificates. They were installed both at the user and at the local machine levels as trusted authorities, without and with administrative rights. They were also imported into the browsers, all the while every endpoint has CORS enabled. Still, the errors remain and I am unable to seize data from a single axios GET call. As expected, when trying to communicate with the same non-secure (http) API, all calls go through without issues. Additionally, Postman and curling both yield desirable results in every case.
I have not found a way to bypass this error so that I can move on with my implementation. I have also advised several other questions here, like:
How to generate a self-signed SSL certificate using OpenSSL?
Getting Chrome to accept self-signed localhost certificate
accepting HTTPS connections with self-signed certificates
Any assistance is most welcome. I bid you all a lovely day!
I deployed a site but I cannot visit it due to HSTS.
I've tried contacting Namecheap, who I purchased the domain from, but they said the problem is with the hosting I am using. I am using surge.sh and have followed their custom domain instructions.
A picture of the error:
A picture of Namecheap:
I expect to be able to visit my site, but I cannot.
The issue isn't the dns configuration. HSTS (HTTP Strict Transport Security) means that the site can only be accessed over an encrypted (HTTPS) connection. Probably due to using a TLD (top-level-domain) like *.dev that requires the use of HSTS. To make this work you need to set up a certificate on your host.
Apparently surge.sh provides free certificates for <my-subdomain>.surge.sh, but you'd need one for your custom domain and Securing your custom domain with SSL is part of surge plus. So you'd have to purchase it and follow the instructions or use a different host that works better for you.
I know many people like to use surge.sh as nice free host for static sites, but in this case you need their paid plan. There are other platforms that allow certificates for custom domains on the free plan though. I'm using netlify with custom domain and https myself on a free plan.
I have a portal that, for legacy reasons, have multiple domains.
On the portal settings, i set to redirect all alias to the primary alias.
Works fine for http, but if the url to the non primary domains has specified https protocol the user gets a 404 error.
Portal is running on dnn version 8.0.3.
To my knowledge, the core in no way supports SSL. There are two 3rd party solutions for SSL you can buy that I know about:
SSL Module 3.2 from Thomas Thorpe (http://www.snowcovered.com/snowcovered2/Default.aspx?tabid=166&CatalogItemID=1505&CatalogID=7&search=SSL&pagenumber=0&sortby=&tagid=-1)
SSL Redirect 1.0 from Sanibel Logic LLC (http://www.snowcovered.com/snowcovered2/Default.aspx?tabid=166&CatalogItemID=3155&CatalogID=7&search=SSL&pagenumber=0&sortby=&tagid=-1)
I currently use the first one and it does the job. I am using version 3.1 of it, and I have experienced some issues with it around the setting of the redirects it lets you configure. But, if you don't touch that, and just use a basic configuration, it works. Also be cautious that it says it supports a shared SSL certificate environment (like a common SSL cert you get in a basic shared hosting account), which it does, but it will only support this for a single portal because it forces you to add that shared SSL domain in as a portal alias. Because portal aliases are unique, you can only set it up for a single portal, not all portals on your host. It looks like he is up to version 3.2 now, so these things may have changed.
I have not used the second module. It looks like it takes a little different approach from the first and allows you to setup general SSL rules for all portals on a host, instead of configuring each portal specifically.
Both I believe require you to make a change to your web.config to add an additional httpModule. They do this to intercept web requests to pages, and if it decides it is a page you have said you want to be secure, it then redirects to the same page with the https prefix and vice versa before any content is sent to the user . I don't think this is the ideal solution because of the multiple server hits involved, but it works.
Credit: dnnsoftware/com/forums/threadid/21470/scope/posts/how-to-set-https-instead-of-http-for-portal-alias
We have an App Engine app that hosts an internal HR/intranet system. Some, but not all, of our users are reporting that they get a security warning (see he image below). It looks like the wrong SSL certificate is being served. I install a wildcard cert for our domain in the Google Apps cpanel, but it looks like Google's certificate is being served instead. How do I go about troubleshooting this?
If some but not all users get this warning you might check what is so special about the users which get the warning. Do they use a specific (old?) browser, are they behind some kind of firewall or similar things? It might be that SNI (server name indication) is an issue, but it is really hard to say from the existing information. It is not even clear what the existing certificate should be so that one cannot compare if the host serves both, one with SNI and one without.
Apart from that it I would consider it a bad idea to host an internal HR/intranet system on the public internet.
We are starting a very large web based service project. We are trying to decide what hosting environment to use. We would really like to use Google App Engine for scalability reasons and to eliminate the need to deal with servers ourselves.
Secure logins/registrations is very important to us, as well as using our own domain. Our target audience is not very computer savvy. For this reason, we don't want to have the users have to sign up with OpenID as this can't be done within our site. We also do not want to force our customers to sign up with Google.
As far as I can see, I am out of luck. I am hoping to have a definite answer to this question. Can I have an encrypted login to our site accessed via our domain, without having to send the customers to another site for the login (OpenID/Google).
Thanks.
The hardest part is getting around the cookie issue. While you can do secure and custom logins against https://yourdomain.appspot.com, you cannot set a cookie there that will work on http://yourdomain.com.
Here is what I propose:
When you need to log the user in, send them to https://yourdomain.appspot.com. If they enter the credentials properly, create a one-time token and place it either in the datastore or in memcache. Give it a lifetime of a few seconds.
Then redirect the user back to http://yourdomain.com/authenticate?token=mytoken (obviously substitute the names as appropriate), check to make sure that the token is valid and has not expired, and if all is clear, set the appropriate cookies and expire the token.
I think that'd work just fine. Hope it helps!
As of June 27, 2012, App Engine supports SSL for custom domains.
http://googleappengine.blogspot.com/2012/06/google-app-engine-170-released-at.html
There is nothing stopping you from creating your own authentication/registration mechanism with Google App Engine. The only problem is that Google App Engine currently only supports HTTPS via https://yourid.appspot.com and not your Google Apps Domain (i.e. https://www.foobar.com). However, this is on the product roadmap for future support (SSL for third-party domains). Note, also on the product roadmap is built-in support for OAuth & OpenID.
Update: Another option may be to use a proxy server (like Apache with mod_proxy) and map your domain to the proxy server and then the proxy server can proxy the HTTP and HTTPS requests to Google App Engine. The requests could be proxied to the appspot.com domain behind the scenes. I haven't actually done this, but I believe it should work. However, this would give you a single point of failure at the proxy server which basically defeats the purpose of Google App Engine's high-availability and scalability. This would definitely just be a short-term solution until Google supports SSL for third-party domains or OpenID.
Depending on whether your threat model can accept a non-encrypted link on the "last hop" to GAE, you can use a proxy to handle SSL from the browser. Here's a HOWTO I wrote up on using CloudFlare to get always-on SSL:
http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine
This isn't structurally any different than the way SSL from Google will work, it's just that Google-provided SSL will terminate within G's network rather than just outside it. If you're trying to protect against Firesheep, CloudFlare (or any other SSL proxy) will do fine. If you're worried about snoops on the trunk connection between CF and Google, you may want a more sophisticated solution.