I've been trying all day to set up my instance of TFS2017 to work with HTTPS.
I've read the official setup guide, but it didn't help much.
My instance is attached to a domain and configuration has been made with an Administrators group user. The domain account is referenced as an administration console user properly.
The setup has been made with default 8080 port and domain account user can access the website as expected (hosted at http://machine-name:8080/tfs)
Now, when I change the IIS website settings binding to use HTTPS on port 443 with a valid wildchar certificate + set the hostname to be tfs.mydomain.com + ask for SSL require, I cannot have my user to authenticate anymore.
I make TFS Public Url point to https://tfs.mydomain.com/tfs.
I get prompted for the authentication box, but after many attempts, the site would just fail with 401.
The tests are made into the server environment to avoid Firewall confusions.
My instance has two network cards with 2 separate networks. First resolves to public IP, second resolves to private IP. I noticed the configuration works with the machine names, while it fails with the DNS resolution on the public IP. Could this be a reason ?
Thanks for your help
To perform the procedures in your requirements, you must first meet some prerequisites such as required Permissions and so on. Please double check this first. Also please make sure you have set up the corresponding ports such as below prompted.
Important:
The default port number for SSL connections is 443, but you
must assign a unique port number for each of the following
sites: Default Website, Team Foundation Server, Microsoft Team
Foundation Server Proxy (if your deployment uses it), and SharePoint
Central Administration (if your deployment uses SharePoint).
You should record the SSL port number for each website that you
configure. You will need to specify these numbers in the
administration console for Team Foundation.
There is a very detail tutorial about configuring HTTPS with SSL, please refer Setting up HTTPS with Secure Sockets Layer (SSL) for Team Foundation Server
To narrow down the issue with IP, you could disable one of your two network cards. Give a test with only using one network card each time.
Related
I have one scenario where I am working on the IIS Website Configurations for URL Routing.
I have added the website and Import the required Certificates on the server.
My scenario is (I have multiple website URLs and two SSL Certs - as below):
qatest1.abc.com
qatest2.abc.com
qatest3.abc.com
Above 3 URLs need to be configured on one SSL Certificate - which is QA Certificate.
Another URL is:
perftest.abc.com
And for this URL there is a separate certificate as PERF (performance) certificate.
This is how the Task is given to me to configure the IIS Settings on MS IIS 10.
Now the Issues which I am facing is:
Not able to configure all the URLs configuration on the same IIS, as per the task given to me I am supposed to configure them all on the same IIS.
Getting a strange message (image attached) and it won't allow me to configure all my above website URLs on the same machine, on the same IIS.
Also trying to read about SNI (But Not sure about how to make use of SNI in this case).
Need help from IIS Experts who can support me on this activity to complete.
you could check the Server Name Identification by using this you can avoid the certificate prompt.
This feature offers an easier solution to hosting multiple sites that have a different or individual SSL on a single IP address.
Each HTTPS binding requires a unique IP/port combination because the Host Header cannot be used to differentiate sites using SSL.This is because the host header is not visible during the SSL handshake.
Server Name Indication (SNI) allows the server to safely host multiple TLS Certificates for multiple sites, all under a single IP address.
#1 - its possible via CLI commands (appcmd & netsh) or scripting (PowerShell) and programming (c#) but not with the IIS Manager GUI afaik.
#2 - (see #1). IIS Manager is stupid and will overwrite existing bindings with the last certificate selected. You end up with bindings attached to the wrong certificate if you click Yes. This is a limitation of IIS Manager GUI not IIS.
#3 - You want SNI turned on. It means you can have multiple certificates associated with the same IP address. Without SNI you would need 1 IP address per certificate
These 2 links will give you an idea how to use appcmd and netsh - this is the quickest/easiest way to create your desired configuration.
Adding a HTTPS binding to a site
Binding a certificate with netsh
If you know PowerShell("POSH") you can use the IISAdministration PowerShell cmdlet New-IISSiteBinding to create bindings and associate with a certificates thumbprint (though netsh is still useful for debugging and fixing issues).
Either approach your really configuring 2 things - IIS' bindings and Windows/SChannel/HTTPS.sys (the operating system component actually responsible for the 'S' in 'HTTPS'). Sometimes they get out of sync and the easiest fix is to delete and re-create the bindings (after clicking yes to "At least one other site is using the same HTTPS binding..." for example).
Few tips:
Once you start using this configuration IIS Manager or Windows Update/software installs will probably break your bindings at some point. Write a script that can remove and re-create all your bindings for port 443(only!) so you can easily fix future issues.
If you use netsh - its very fussy about the syntax. Order and spacing of parameters are important when using command netsh http add sslcert.
While your testing netsh http show sslcert and netsh http delete sslcert are very useful to try different configurations (this wont delete the cert, just the binding)
Cert needs to be in the Machine certificate store and make a note of the path. When using POSH or netsh always specify both certificate thumbprint and the store\path where the cert was installed.
If you need a default HTTPS binding on the IIS Site (eg load balancer healthchecks etc) add it before any named HTTPS bindings.
Final aside - if your domains are all 1 level under abc.com getting a wildcard certificate would save you a lot of bother. a single *.abc.com certificate would cover all your domains and you can avoid this limitation entirely.
Good luck!
In my example I am using https://portmap.io VPN service which is not exactly a pure VPN services but still uses VPN technology to break my ISP restrictions, allowing portforwarding to my own home server running in my android device.
So if I run 193.161.193.99:1200, my website gets browsed. The port 1200 is mapped to my local python server port running on port 1000. Port 1200 is given by the VPN provider.
However, if I try 193.161.193.99 without the port 1200. The portmap VPN official website gets called, cause that's the websites' IP. So basically each user of this VPN services has there own port to work with.
Question: I don't have any public IP totally in my own control to get an SSL certificate, which requires a file upload verification by the CA (CSR). So, it it anyhow possible to get an SSL certificate using 193.161.193.99:1200 ?
Note: Services like zerossl.com accepts to provide a certificate for ipv4 public addresses. So it not always essential to use a FQDN to get a cert.
Yes this is possible, you will need a domain pointing to the VPN/portmap IP and then obtain a SLL certificate from Let's Encrypt for that domain. This can be your own domain or one provided by a Dynamic DNS Service such as Duck DNS.
I'll describe how I have done it with Docker and Duck DNS in detail:
Sign in to Duck DNS, create a subdomain and point it to the VPN/portmap IP, note the token at the top of the page.
Deploy a docker container from LinuxServer.io's SWAG Image
Make sure to provide the required environment variables in your docker-compose.yml (or with docker run command):
- VALIDATION=duckdns
- DUCKDNSTOKEN={your token}
- URL={yourdomain}.duckdns.org
Note: If you want everything behind your VPN, there is a great docker container called gluetun which allows you to run the swag container behind your VPN
You will find your SSL certificates in the /config/etc/letsencrypt/live/{yourdomain}.duckdns.org folder of the SWAG container. Use those for the website/service that is running behind your forwarded port.
The certificates will get updated automatically 30 days before they expire. There is also a PKCS#12-file privkey.pfx, which is needed for services like emby. For more information on SWAG see the LinuxServer.io Docs. You may or may not need another container running that updates the Duck DNS IP periodically, I'm not sure if the SWAG container already does that.
All of this can of course be done without Docker and with your own domain. In this case you will need to map your domain or subdomain to the VPN IP in the DNS Record section of your domain provider. And then use certbot to create certificates for that domain. Docker just automates the renewal part.
I've created literally dozens and dozens of web servers in my day, but this is my first attempt with Windows Azure and I'm running into some problems. I just started migrating from AWS recently.
First of all, I'm running Ubuntu 13.04. Firewall disabled (for debugging), Apache2 installed correctly (using apt). SSH works fine as do many other services with both the DNS hostname and public IP. Virtual host is set up correctly and validated. However, I cannot access the HTTP website either through the Azure provided subdomain or the virtual IP. It just times out.
This is also my first time using Ubuntu 13.04 as well. So, through the powers of deduction, I'm assuming there is something I'm missing either with this new version of Ubuntu or some quirk in Azure. Does anyone have any suggestions?
SOLUTION
These steps to create "endpoint" works fine for all VPS:
open "virtual machine > endpoint > add endpoint"
choose "next"
set "name:http, protocol:tcp, public port:80, private port:80"
choose "complete"
and then must wait for activation and then for some time.
If you are using Azure Resource Groups along with your VMs (which is available on the new portal) you cannot use endpoints because it's not available there, so you should follow the following to open up the HTTP port or ANY other port:
1- Select the VM that you want to manage ports on.
2- In settings, click on Network Interfaces and select your network.
3- Go to Network Security Group and select your group.
4- Add Inbound or Outbound security rules depending on what you need.
using IIS 6
I have the default web site that works and can authenticate users to the domain when they connect.
I have created a second website, siteb, put a host (a) record into DNS, I can browse to it as long as I have use anonymous access, when I select windows authentication, it fails...
not sure what i'm missing here...
Thanks.
This goes beyond just IIS if you're using Integrated Windows Authentication. You've created "siteb" in DNS which allows your users to connect to it so this is good. However, when their browser requests a Kerberos ticket for "siteb" from Active Directory, AD is probably responding that it cannot find "siteb". You can verify this with Wireshark.
The fix is to add "siteb" (and any other permutations with which you expect users to access the site) as an additional servicePrincipalName for the server's machine account in AD. You can accomplish this with the "setspn.exe" utility. It should be available on your domain controller. If not, you can install it from the Windows 2003 Support Tools.
Some examples of adding a UPN alias with setspn on the DC are:
setspn.exe –A HTTP/siteb <server hostname>
setspn.exe –A HTTP/siteb.acme.com <server hostname>
This should take effect immediately. The final step is ensuring that the browser "trusts" the new website name. In Internet Explorer, for IWA to occur automatically, the server name should be listed in either the Trusted Sites or Intranet zone.
Of course, you could avoid all this hoopla by having the 2nd website just run on a different port under the same name, e.g.: http://sitea:81
Context
I developed an application deployed in a Glassfish 3.1. This application is accessed only by https and sometimes it must connect to third-party webservices located out the customers networks. The customer have other applications inside his network; mine is only a new one "service".
Topology approximation
Big-ip F5 is the ssl end point. The customer have in this device the valid certificate
IIS redirects by domain to the respective service
glassfish is the machine with the application (over, of course, a glassfish 3.1)
How it works
When a user try to connect to _https://somedomain the request arrives to the F5 where the SSL encryption ends; now we have a request to _http://somedomain. In the next step F5 redirects this request to the IIS and this, finally, redirects to glassfish. This petitions are successfully processed.
Points of interest
I've full control over glassfish server and S.O. of the vm where it is located. Not other applications are or will be deployed on this server; it's a dedicated server for the app and some services it needs. The Glassfish runs on a VM with a Debian distribution as S.O. This VM is provided by a VM Server but I don't know the brand, model, etc. The glassfish have the default http listeners configuration.
I don't have any more information about network and other devices and i can't access to
any configuration file of any other device. I can't modify any part of the network for my own but maybe ask, suggest or advice for a change. Network's behavior should not change.
Actually users reach the application without problem.
The used certificate is a simple domain certificate trusted by Verysign
The customer have no idea of how to solve this.
The problem
All the third party WS the application must access have an unique https access and, in some cases, the authentication required is mutual (two-way) and here we find the problem. When the application wants to connect to WS with mutual ssl authentication it sends the glassfish local keystore configuration targeted certificate. Customer wants, if possible, use the same cert for incoming and outcoming secure connections. This cert is in the F5 and i can't add to the glassfish keystore because if I do this I would be breaking Verysign contract requirements. I've been looking for a solution at google, here(stackoverflow), jita,... but only incoming traffic solutions I've found. I understand that maybe a SSL proxy is required but I haven't found any example or alternative solution for the outcoming ssl connections.
What I'm asking for
I'm not english speaker (isn't obvious?) and maybe i doesn't use the correct terms in my search terms. I can understand that this context can be a nightmare and hard to solve but I will stand... The first think I need is to know if exists a solution (or solutions) for this problem and if it (or they!) exist where or how can I find it/them. I've prepared different alternatives to negotiate with the customer but I need to known the true. I've spent tones of hours on this.
There are a couple of solutions.
1)pay verisign more money for a second "license/cert". They will be happy to take your money for the "privilege". :)
2)Create a different virtual server listening on 443 which points to a pool that has your client's server address as the pool member. Then on the virtual server, attach a serverssl profile that is configured to use the same cert you are using for the incoming connections. Then the F5 would authenticate with the same cert along with your app server would not need a client cert installed. Also, if they need to initiate a session to you, you would have to setup a virtual server with a clientssl profile that uses the same cert and requires a client cert to connect.
If your destinations may not be static addresses, then an irule(s) would have to be created to deal with that. Can be handled in 10 or later code with a DNS call in the irule and setting a node for the session to go.