When attempting to contact a server running the Certification Authority Web Enrolment role, you may see the following error.
In order to complete certificate enrolment, the Web site for the CA must be configured to use HTTPS authentication
Solution
The correct fix is to set the web server (IIS) to serve the certificate website securely using https, though you can just set Internet explorer to ‘work’ from your client machine if you are in a hurry.
Make Internet Explorer Accept Your Certification Authority
Note: This would need to be done on every machine that you wanted to access the Certificate Services web portal from.
1. From within Internet Explorer > Internet Options > Security > Trusted Sites > Sites.
2. Untick ‘Require server verification (https:) for all sites in this zone’ > Then add in the URL of the CA > Close.
3. With Trusted sites still selected > Custom level > ‘Initialize and script ActiveX controls not marked as safe for scripting’ > Enable > OK > Yes.
4. Restart the browser and try again.
Set IIS to serve Certificate Services Securely (via https).
This assumes you have your CA and the web portal installed correctly.
1. On the Certificate Services Server > Launch IIS Manager > Expand {server-name} > Sites > Default Web Site > Right Click > Edit Bindings > https > Edit > Select the self signed server certificate [NOT the CA ONE] > OK.
Note: If https is missing simply add it!
2. Expand Default Web Site > Certsrv > SSL Settings.
3. Tick ‘Require SSL’ > Apply.
4. That should be all you need, if it does not take effect straight away then drop to command line and run iisreset /noforce.
Related Articles, References, Credits, or External Links
If you have a host that you want to be able to access from the outside of the firewall e.g. a webserver then this is the process you want to carry out. I didn’t find this process particularly intuitive and it highlighted why I don’t like GUI management interfaces, (in 6.4 the menu names have changed, this rendering a million blog pages inaccurate!)
I’m setting this up in EVE-NG on the work bench and this is what I’m trying to achieve;
So to access my web server from ‘outside‘ the firewall I need to give it a NATTED ‘public‘ address on 192.168.100.0/24. Here the server is on the LAN if yours is in a DMZ then substitute the DMZ interface for the inside one I’m using.
Solution
First task is to create a ‘Virtual IP‘, this will be the ‘public IP‘ that the web server will use. From the management interface > Policy and Objects > Virtual IPs > Create New > Virtual IP
‘Give it a sensible name, and add a comment if you wish > Set the interface to the public facing port > Type, set to ‘Static NAT‘ > External IP, (although it says range just type in the single public IP) > Internal IP = Enter the LAN IP > OK.
Firewall Policy > Create New.
Note: If your firewall is older then 6.4 the tab is called ‘IPv4 Policy‘
Give the entry a name > Incoming interface = the public interface > Outgoing Interface = the inside/LAN interface > Source = ALL > Destination = SET TO YOUR VIRTUAL IP > Schedule = Always > Service = ALL (though you can of course select http and or https in production) > DISABLE NAT. (Trust me I know that makes no sense) > OK.
Just to prove this is not all ‘Smoke and Mirrors‘ here’s my topology running in EVE-NG, and my external host (Named: Public-Client) Browsing to 192.168.100.110, and the Fortigate translates that to 192.168.1.123
Related Articles, References, Credits, or External Links
I’ve been trying to deploy a Fortigate into EVE-NG (article to follow) this week. I could get the appliance running fine but when I tried to access the web management console all I got was the following.
Note: I have a couple of management VMs in EVE-G (Windows 7 and Server 2012), they had a mixture of IE, Chrome and Firefox on them but still I could not get in?
Solution
All forums yielded no more info other than ‘Check you have allowed access for http“. But as you can see (above) for Fortinet Logo is on the windows I was hitting the firewall and http was allowed? (Also the http daemon was running inside the appliance.
Just for fun I connected the outside interface to my test network, allowed http, and tried from there, it worked perfectly? So I deployed another Fortigate and connected the ‘inside’ interface to my test network, again it worked fine? At this point it was becoming obvious that my management machines browsers were probably the problem. Is I deployed a new Kali Linux VM fired up Firefox and;
That took a LOT longer than it needed to!
Related Articles, References, Credits, or External Links
In past articles I’ve got my F5 BIG IP appliance up and running, and I’ve built some web servers to test load balancing. Now to actually connect things together and start testing things. Below is my lab setup, I will be deploying simple web load balancing (Static: Round Robin) between three web servers, each serving a simple HTTP web site.
Test F5 to Web Server Connectivity
For obvious reasons the F5 needs to be able to speak to the web servers, so it needs to be on the same network/VLAN and have connectivity. To test that we can log onto the the F5 console directly, and ‘ping’ the web servers.
So connectivity is good, let’s make sure we can actually see the web content on those boxes, the best tool for that is to use curl, which will make a web request, and the wen server ‘should’ return some HTML.
[box]curl http://10.2.0.11[/box]
F5 BIG-IP Load Balancing Terminology
Yeah I said ‘load balancing‘ and not ADC sue me! There are a number of building blocks that F5 uses, and you need to understand the terminology to put things together, firstly lets look at things BEHIND the F5 appliance;
Node: An actual machine/appliance, (be that physical or virtual.) That provides some sort of service or a collections of services e.g. a web server, telnet server, FTP site etc.
Pool Member: Is a combination of a Node AND a Port/Service, e.g. 192.168.1.100:80 (IP address and TCP port 80 (or HTTP)).
Pool: A Logical collection on Pool Members, that provide the same service e.g a collection of pool members offering a website on TCP port 80.
F5 BIG-IP Adding Nodes
While connected to the web management portal > Local Traffic > Nodes > Create (Note: You can also press the green ‘add’ button on the Node pop-out on newer versions).
Specify a name > Description (optional) > IP address (or FQDN) > ‘Repeat‘ > Continue to add Nodes as required, then click ‘Finished‘.
F5 BIG-IP Adding Pools
Now we have our Nodes, We need to create a Pool. Local Traffic > Pools > Create, (again on newer versions theres a green add button on the pop-out).
Add a Name > Description (Optional) > Add an applicable Health Monitor (in our case http) > Select the ‘Node List’ radio button > Select your first Node > Set the Port/Service > Add > Continue to Add the remaining Nodes.
Note: Here is where you add the IPs to the Port/Service and create the Pool Members.
Sorry! Busy Screenshot
When all the Nodes are added > ‘Finished‘.
Your web pool ‘should‘ show healthy, Note: that does not mean ALL the nodes are online!
To make sure ‘all’ the Nodes are healthy > Go to the Members Tab.
F5 BIG-IP Virtual Servers
I’m not a fan of using this term ‘Virtual Server‘ I prefer Virtual IP (or VIP,) but we are where we are! Above we’ve looked at things BEHIND the F5, now we need to present those services IN FRONT of the F5 (Note: I don’t say publicly, because we deploy plenty of BIIG-IP solutions inside networks). So a Virtual Server is the outside IP address or FQDN of that a ‘consumer’ will connect to;
Local Traffic > Virtual Servers > Create.
Supply a name > Description (optional) > Destination Address (the ‘available outside’) IP address > Set the service/port > Scroll down to the bottom.
Set the ‘Default Pool’ to the pool you created (above) > ‘Finished‘.
For a brief overview or check what you have created > Click Local Traffic > Network Map Note: This will look different on older versions of the F5.
Then test the service form the outside, here each web server serves a different colour page so I can test it’s working properly.
My Web Page Does Not Change? If you keep seeing the same colour/page then it’s probably because you chose browser is ‘caching’ web content on your test machine, you may need to disable caching on your chosen web browser, for an accurate test.
So that’s Static Round Robin (Equal Ratio) Based Load Balancing. In the next article I’ll look at how you can manipulate the ratios, to better serve your hardware, and requirements.
Related Articles, References, Credits, or External Links
Rather by accident I discovered this was not working on the site. I know it used to work, but when the old certificate expired last year I was on holiday in The States, and had a panic trying to disable https, (to keep the site up until I got back and bought a new cert). So I’m guessing its been broken since then.
Solution
I spent about two days looking at forums about how to do this, and every time I edited the NGINX default file, the site stopped working. In the end I found one post in the middle of a discussion about this and that was the ONLY solution that worked for me.
Paste the following WITHIN your server block.
[box]
# Force HTTP to HTTPS Redirection (Entire Site)
if ($scheme != "https") {
rewrite ^ https://$host$uri permanent;
}
[/box]
Related Articles, References, Credits, or External Links
I seem to get all the PKI/Certificate services problems! Yesterday I was trying to use the web enrolment portal on a certificate services server, and could not get in locally, (or remotely) via http, (or https) it simply showed me a 403.14 error.
HTTP Error 403.14 Forbidden
Solution
This was an odd one, in IIS Manager select the ‘Certsrv’ virtual directory > Advanced Options > And look at the ‘Path’.
Mine was missing the ‘en-us‘ folder from the end of the path!
Note: You will need to open an administrative command window, and then execute an iisreset command, before the change will take effect.
Related Articles, References, Credits, or External Links
Here is the simplest load balancing scenario I can think of, I’ve got two web servers, (on http port 80) and I’m presenting them though my NetScaler as an HTTP (Virtual Server).
Solution
First we add the ‘back-end’ servers. Connect to the management IP of your NetScaler and login > Configuration > Traffic Management > Load Balancing > Servers > Add.
Define a name for the first server and enter its IP address > Create.
Repeat to add the second internal web server.
Now I’m going to group these servers together in a ‘service group’, (you don’t have to, you can present them individually to the virtual server you will create in a minute if you prefer). Configuration > Traffic Management > Load Balancing > Service Groups > Add.
Name the group and set the protocol to HTTP > OK.
When created, you will see it says ‘No Service Group members’ > Click there.
Select ‘Server Based’ > Click the search arrow.
Tick them all > Select.
Set the port (HTTP is TCP port 80) > Create.
OK.
Now we need to add a monitor, this is what the NetScaler will use to monitor the service availability of your ‘back-end’ servers on TCP port 80 (HTTP). Click Monitors.
This confused me for a while, selecting things on the right, drops them at the bottom of the main page > Click ‘No service Group Monitor Binding’.
NetScaler has a monitor for http pre-configured, so I’m going to use that > Click the search arrow.
Click ‘http’ > Select.
Bind.
Done.
Now we tie all that together in a ‘Virtual Server’ > Configuration > Traffic Management > Load Balancing > Virtual Servers > Add.
Give the Virtual Server a name > Protocol is HTTP > Specify the IP address (this will be the VIP the NetScaler presents to the outside world) > Port 80 > OK.
Now we need the add the group we created earlier, click where it says ‘No load balancing Virtual Servers Service Group Binding’.
Click the search arrow.
Click the group you created earlier > Select.
Bind.
Continue.
Done.
Save your hard work.
You should be green across the board.
To test this I put a different web ‘welcome’ page on both of the servers, that way as I refresh the page I can see that the NetScaler is doing its job and balancing the requests across both back-end web servers.
Related Articles, References, Credits, or External Links
You receive an Event ID 3033 error, with the following description,
‘The average of the most recent <?> heartbeat intervals used by clients is less than or equal to <?>. Make sure that your firewall configuration is set to work correctly with Exchange ActiveSync and direct push technology. Specifically, make sure that your firewall is configured so that requests to Exchange ActiveSync do not expire before they have the opportunity to be processed. For more information about how to configure firewall settings when using Exchange ActiveSync, see Microsoft Knowledge Base article 905013, “Enterprise Firewall Configuration for Exchange ActiveSync Direct Push Technology”
I noticed this a while back, apparently Google Analytics started flagging this for many users on October 14th 2014. But I’ve only just got round to sorting it out.
If you are seeing this error its because your site is ‘addressable’ in more than one way, in my case you could get to me via http://petenetlive and http://www.petenetlive.com. I could have registered both in ‘Google Webmaster Tools’, and set one as a preferred site, but I didn’t want to update my Analytics code (I’ve got custom stuff in there I don’t want to re-write). So my next option is to do a ‘301 redirect’.
Solution
1. I use Apache web server, and I have my own VPS, so I can pretty much do what I want, If you side is hosted you may need to ask them to ensure that the rewrite_module is loaded on your web server. If you have your own you will need to take a look at your httpd.conf file.
2. Make sure that (like below), there is a line that is not commented out, that reads;
3. Now in the root of your website edit (or create) the .htaccess file. And pate the following onto the end of it, (change accordingly);
[box]RewriteEngine On
RewriteCond %{HTTP_HOST} ^petenetlive.com
RewriteRule (.*) http://www.petenetlive.com/$1 [R=301,L][/box]
4. Save and upload the file (If using Notepad, make sure it does not put a .txt extension on the end of the filename – it should have NO extension).
5. Now go to http://your-website.com, (It will probably still work because your browser will attempt to load the page from its cache, so press CTRL+F5 to force refresh). If should redirect to http://www/your-website.com
6. To make doubly sure you can go here and type in http://your-website.com it should say something like;
HTTP/1.1 301 Moved Permanently Date => Thu, 04 Dec 2014 19:41:48 GMT Server => Apache/2.2.15 (CentOS) Location => http://www.petenetlive.com/ Vary => Accept-Encoding Content-Type => text/html; charset=iso-8859-1
<
7. Back in Google Analytics, select ‘Check again’.
5. It should say this.
6. Then it will say this ‘for ages!’.
Related Articles, References, Credits, or External Links
This procedure was carried out on a Draytek Vigor 2800 Router, for this I needed to forward RDP (That’s on TCP Port 3389).
Warning: If you need to forward any of the following ports 23 (Telnet), 80 (HTTP) , 443 HTTPS/SSL), 21 (FTP), or 22 (SSH). The Draytek has these reserved for remote management. You will need to change the port number (system Maintenance > Management > Management Port Setup).
Solution
1. Log into the routers web console (default will be a blank username and password, or admin and admin, or admin and blank password).
2. Give the service a name (Like RDP) > Enter the protocol type TCP or UDP > Enter the internal IP that you want to forward the port to > Tick active > Click OK.
Note: Depending on setup you may see this instead (if that’s the case select the correct public IP)
3. That should be all you need to do, unless the firewall is turned on, if that’s the case expand NAT > Open Ports.
4. Again enter a name in the comment box > The local IP of the machine > and the port details > OK.
Related Articles, References, Credits, or External Links