Why Cloudbees doesn't allow wildcart domains by default? Heroku makes really easy for user to add/remove wildcart domains like *.me.com. I filed a ticket over 24 hours but still there is no one trying to resolve that ticket.
Wildcard SSL domains are supported by RUN#cloud, however it is not exposed in the user interface.
As to why it's not in the UI - it's not a common request, and as such hasn't inflicted enough pain on support to warrant implementing a user configurable interface for it as yet.
There is further information on Custom Application Domains, wildcard domains and how to raise a request with the appropriate information at https://wiki.cloudbees.com/bin/view/RUN/Custom+Application+Domains
Related
I have a website running on IIS that requires two SSL certificates, one for the main website domain, and one for the traffic coming through a CDN (the assets are served from a different domain name). Both use SSL.
I therefore used the Server Name Indication option when creating the HTTPS bindings in IIS.
The site works fine, I know that users on IE6/Windows XP may experience an issue, but we don't have any/many users visiting our site using that combination so that's not a problem. However, it is an ecommerce site that receives postbacks/callbacks from both PayPal and WorldPay. Here is where we are experiencing an issue. It would seem that neither PayPal or WorldPay's mechanism for posting back payment information understands SNI, therefore we don't get notified that a payment has been made.
I'm not sure what the options are. IIS is telling me to create a default SSL site, but I can't find any instructions online regarding what I should be creating, or what benefit it serves.
Am I going down the right path with this? Can anyone offer any advice on a) whether a default SSL site will fix this issue and b) how to create the default SSL site?
Thanks for your time in advance.
Kind regards,
Dotdev
You don't have to have all your sites configured to require SNI.
From what you're saying, your callbacks from PayPal and WorldPay are on your main site are they?
If this is the case, you can simply edit the binding on your main site so that it does not require SNI, and make sure it is set to "All unassigned" rather than a specific IP address (otherwise it will get in the way of the SNI site).
I have the following requirement. I have many users log into my system either from within my domain (intranet and on the VPN) or from outside the domain from public internet. I would like to know from where users log in and route them separately. (bind them to specific endpoints on a WCF service)
I tried using the "Environment" variable. But there is one special case that I would like to address. People who have a laptop that is registered in the domain always show as "Being in Domain" even when logging in from an outside network. How do I go about solving this?
Any help would be appreciated.
I'm not sure if you can reliably do this. I think the best course of action would be to have an internal server and an external server (or at least two separate applications, one accessible from the local intranet and one accessible from the internet. When accessing the application internally the companies internal DNS would route to the internal version of the application. And externally would route to the external version of the application.
There are similar questions here,
How to detect if machine is joined to domain (in C#)?
and here
Detecting a users domain in asp.net
I'm working on a project the requires me to register a domain for a user based on input. I want an API that I can call that will let me register a free domain for the user. The TLD does not matter, i'm open to things like .co.cc, .co.nr, etc. I already saw the .TK affiliate program, but it seemed a little shady. Again, both the API and the domain have to be free.
Thanks
I'm not aware of any free domain registries. You probably want to look into creating a DNS sub-domain, where if you have the domain "myapp.com", a user can create the subdomain "user1.myapp.com". Those would be free, depending on how you're hosted and who runs your DNS.
is it usually advisable to install a single domain ssl certificate to the main domain --domain.com and use .htaccess to go in and out of ssl or to a subdomain such as --secure.domain.com. I know there are different needs for different sites but I'm asking for the average websites needs. -eg a website owner wants a secure shopping cart for their customers should they use domain.com/secure and force ssl or have ssl on secure.domain.com
I would install it on the main domain name. It sounds better to put it on a sub domain but then you technically have a whole separate website to maintain and this could be a negative rating for search engines. Also, need another SSL certificate if you want anything secure on your main site.
Depending on your back end technology (i.e. - .NET, ASP, PHP), it only takes a couple lines of code to check the page request and redirect the user to the proper page desired. For example, if a user goes to [http://www.domain.com/secure] you can redirect the request to the proper secure page (https://www.domain.com/secure) and vice versa.
.htaccess is an older technology and can be very cumbersome to use.
Background: Customer X is a low-budget non-profit outfit that nonetheless has a lot of activity configured on virtual hosts, and the virtual hosts multiply very frequently. Customer X also has a lot of users and is interested in getting them over to a single sign on solution. This way, all the users can use the same credentials on all the virtual hosts.
It has also pretty much been mandated that we use [Shibboleth Single-Sign-on](http://en.wikipedia.org/wiki/Shibboleth_(Internet2) to handle the authentication.
Problem: Shibboleth Single Sign On uses SSL as part of its protocol, but getting multiple virtual hosts to use SSL is not a walk in the park.
This question about virtual-hosts with SSL details some of the pitfalls.
Question: What is the best way to proceed with this scenario (summary):
multiple virtual hosts on apache
setting up a distinct IP and NIC for each virtual host is pretty much not an option
SSL pretty much requires a separate IP
they all need some kind of SSO
we are being heavily pressured to use Shibboleth as the SSO provider
Is there anything we may be missing here or some way to resolve this, short of requiring a separate IP for all vhosts?
I have a client with the exact same situation and the way that they solved it was to buy a wildcard domain *.example.com and have all the virtual hosts have a specific subdomain at example.com to get around this problem.
This was with Shibboleth and did work out, although you need the hosts domains to agree to fall under one parent domain for the SSO.
If the data itself you exchange with the given site (the Service Provider) is not security sensitive you can just turn off SSL for accessing the site.
There are two SSL channels we are talking about.
one used when the SP communicates with the IDP
the other is accessing the site
Only the latter one should be a "well-known" (what you have to pay for) certificate.
One can use HTTP artifacts to avoid POSTing data from the idp (which is SSL protected) to the SP which is not. This way the browsers security warning can be avoided.
This setup still protects user credentials. The data you exchange with the site will be not.