jump to navigation

IIS5 and intermediate certificates April 25, 2011

Posted by jamesisaac in Uncategorized.
Tags:
add a comment

Notes regarding renewing an SSL certificate – we use Thawte for some of our SSL certs and in the past year they have moved to using intermediate certificates (along with everyone else). When you renew the certificate in IIS5, on a Windows 2000 server, you can either get the PKCS #7 cert which contains the intermediary certificates, or do like I did and get the x.509 cert because that’s what you used last year.

Once applied, you will find that SSL breaks because the certificate path can’t be verified. Oh noes. So quickly go back to IIS and replace your current certificate with the previous one (you do have a couple of days before it expires, right?)

Then go to the SSL provider’s website and download the intermediate certificates. In Thawte’s case, they are located here:

https://search.thawte.com/support/ssl-digital-certificates/index?page=content&actp=CROSSLINK&id=SO14996

Download the SSL CA and the Primary Root CA. Create a new MMC for the Certificates snap-in (specifying the Local Computer as the target), and then import the certificates. They should import successfully.

After they are imported, you can go back to IIS and replace your old certificate with the new one you added earlier, and then verify that the SSL path is verified from the root to the intermediate to your new cert.

Advertisements

Barracuda WAF and intermediate certificates October 4, 2010

Posted by jamesisaac in Uncategorized.
Tags: ,
3 comments

We purchased a Barracuda Web Application Firewall in order to protect our web servers from layer 7 attacks (SQL injection attacks, cross-site-scripting, etc.). The WAF works just like a network firewall in that you define an inside server (the “real” server), an outside ip address that it will respond to (the “virtual ip”), and the WAF then receives all traffic to that public ip, inspects it, and passes it along to the inside server.

The head-scratching question that I had during my research was this: if the inside server is presenting an SSL service, how does the WAF inspect the traffic? The answer is pretty straightforward: you move the certificate from the server to the WAF. It then unpacks the encrypted packets, inspects them, and forwards them to the server. You can specify whether you want to forward the traffic encrypted, in which case the WAF re-encrypts the packet and sends it to the server, or unencrypted (on port 80). Doing this reduces the load on the server since it doesn’t have to decrypt and encrypt the packets, but it does expose the traffic to your internal network in an unencrypted state.

Straightforward, I said, right? Well, yes. Except for the parts which aren’t straightforward, which is nearly everything in this case.

The Barracuda WAF accepts certificates in .PEM format, which our third-party CA doesn’t provide. There’s some documentation on how to get the certificate from your server, but it’s none too clear. In our case, we are using IIS, so I went to the IIS Admin applet and exported the certificate. It exports in a .pfx format, which can’t be read directly by the Barracuda WAF. You need to use OpenSSL to change the format of the key from .pkx to .pem, and also to extract a non-encrypted key-only version as the two go together. This isn’t listed in the documentation, by the way, only some serious Google-mojo turned up the interesting documents. Here’s Scott Lowe’s documentation on how to do it; you should end up with a .pem file containing the cert itself and then a .key file containing the key.

Now upload the certificate into the Barracuda, create the https service, and away we go, right? No. Because earlier this year Thawte (as well as most other CA’s) changed from having a single root certificate to using a chain of intermediary certificates. This improves security so I guess it’s a good thing. But it does make installing the certificate more difficult. The Barracuda WAF includes a browse-box selector for intermediate certificates, so I went to Thawte’s root certificate page and downloaded the relevant certs and included them. No dice. The client browser claims that the certificate is untrusted because the entire chain isn’t listed.

By the way, here’s a really good site to test your certificates after they are installed on your server; it provided some helpful error messages in my troubleshooting.

Finally, after more Google-mojo, I stumbled upon the answer: a certificate bundle. Unlike Matt’s problem which he detailed on the Standalone Sysadmin (great blog, by the way), I actually had the reverse problem – the individual intermediate certs didn’t work, and only the bundle saved me. Where to find it? Back to Thawte’s knowledgebase, and I downloaded the bundle listed for Apache. Then back to the Barracuda WAF, upload, and… yes! Verified!

It seems to me that this whole process should be much, much easier to deal with, but right now there are too many standards and formats and methods. Hopefully this will help anyone else with a Barracuda Web Application Firewall who is stymied, like I was, and is looking for some assistance.

VLAN across WAN July 9, 2009

Posted by jamesisaac in Uncategorized.
Tags: ,
add a comment

Stop me if you’ve heard this: you can’t extend a VLAN across a WAN. Or the alternative comment: you can, but why would you want to? After all, a VLAN is a container for a broadcast domain, right? And those are done with local, physical entities. Routers act to block broadcasts, so your broadcast domain can’t extend past a router.

Sure, that’s true to one degree or another. In a bandwidth-constricted environment, forwarding all your broadcasts across a small pipe is a recipe for disaster. But what if you’ve got a larger pipe, say, 10mb ethernet, and you promise that you’ll selectively forward some VLANs and not others? Then can you do it?

I pursued this for practical and theoretical reasons, and found that you can in fact span a VLAN across a WAN with by reaching waaaaay back and building a bridge. Yep, we’re going to bridge that WAN.

I have two routers, with two ethernet interfaces each. Fast0/0 is the inside and Fast0/1 is the outside on both routers. The secret is to create subinterfaces and encapsulate dot1q for your subinterfaces. That puts the VLAN tag on that traffic. Then, just enable bridging for each respective subinterface, and you’re gold.

This config is for Cisco routers. YMMV.

bridge crb

!

!

interface FastEthernet0/0

description Corp local network

no ip address

duplex auto

speed auto

!

interface FastEthernet0/0.1

encapsulation dot1Q 3

ip address 192.168.1.1 255.255.255.0

no snmp trap link-status

!

interface FastEthernet0/0.102

encapsulation dot1Q 102

no snmp trap link-status

bridge-group 102

!

interface FastEthernet0/0.103

encapsulation dot1Q 103

no snmp trap link-status

bridge-group 103

!

interface FastEthernet0/1

description Interface to DC

no ip address

duplex auto

speed auto

!

interface FastEthernet0/1.3

encapsulation dot1Q 3

ip address 192.168.2.1 255.255.255.252

no snmp trap link-status

!

interface FastEthernet0/1.102

encapsulation dot1Q 102

no snmp trap link-status

bridge-group 102

!

interface FastEthernet0/1.103

encapsulation dot1Q 103

no snmp trap link-status

bridge-group 103

!

bridge 102 protocol ieee

bridge 103 protocol ieee

So what I did was, I have built three subinterfaces on this wire. VLAN 3 is routed using a subnet on one side and a different subnet on the other, with a tiny subnet inbetween to glue the two networks together. We use VLANs here even though this is just a routed network because the network ports on either side are full 802.1 trunk ports. VLAN 102 and VLAN 103 are true “broadcast” VLANs. There’s no ip information contained in them, because you don’t use ip routing with a bridge. The secret sauce is configuring a bridge-group for each VLAN and then turning on broadcast traffic with the “bridge 102 protocol ieee” command. This doesn’t show up explicitly in the configs but is not on by default (at least in the version of code I was using).  The other router should be configured identically, except that the VLAN 3 information would be for the local network on the other side. Use the same VLAN encapsulation and bridge-group numbering.

I don’t recommend doing this with your main networks, as you will then be sending all of your broadcast traffic across the wire for (probably) no good reason. I’m doing it to fix some workstation deployment issues using a non-standard PXE boot appliance, as well as just to see if it is possible. Using VLANs in this manner essentially makes your VLAN’ed network portable between physical networks. Since the ip addresses don’t change (remember, it’s not a routed network), you can move your devices around from one site to another without having to renumber them. Keep in mind that their default router may be on the other side of the physical network, though, so you may want to fix that once you finish moving devices around.

WAN and VLAN issues July 8, 2009

Posted by jamesisaac in Uncategorized.
Tags:
add a comment

With the arrival of the DSS SANs, the project is moving ahead with great speed. We purchased two SANs from Silicon Mechanics, with the goal of configuring synchronous replication between them. They arrived each in a large box, containing the 2U chassis and a large pink foam insert with each drive packaged up separately. The Silicon Mechanics technicians had loaded the drives, configured the RAID groups, then taken everything apart and packed the drives along with instructions for reassembling everything at the destination site. I assume this improves the reliability by not shipping the storage server with drives installed. They did a very thorough job of protecting everything. The end result is 3.5 TB of fast, SAS-based storage. I’m extremely happy that we are able to use 1TB SAS drives for one of our RAID groups and not have to burn drive slots just to accomodate our larger, but less i/o-intensive vm’s.

I spent a few hours figuring out how to trunk VLANs across the WAN and into the datacenter setup. On the Cisco router side, this involves configuring subinterfaces on the inside and outside interfaces of each router, and setting the “encap dot1q” for each subinterface. It’s an interesting game to play to try to telnet into the appropriate interface and change the ip config of the other interface, so that you don’t cut off the limb that you’re standing on, so to speak. After a few tries I resorted to the console cable and got everything squared away.

The Netgear switches proved to be another mindbender, though, as even though I’ve done this before (and documented it), the VLAN trunking is just not intuitive for someone with a Cisco background. The other troublesome part of the equation is that some devices natively understand and inject their own VLAN information (i.e., the VMWare host servers), but others do not and have to have their native VLAN set at the port. In the end, I found it easiest to set the native VLAN for each device to something other than 1 – that way I was certain that if I was reaching a device, it was through the appropriate VLAN.

Bits and Pieces June 18, 2009

Posted by jamesisaac in Uncategorized.
Tags: , , ,
add a comment

The datacenter-in-waiting is starting to take shape in the corner of the server room. I’ve got the Cisco routers set up so they talk to each other over ethernet, and our new data center network is logically separated from the rest of the network.

  • Configured the Belkin KVM-over-IP. It has a very simple interface; you connect to the web page and *bam*, you’re looking at the server switcher. Nothing extraneous here. Mouse tracking is a little finicky and seems to depend mostly on the “enhanced pointer” control inside the remote OS.
  • Looks like I will have to figure out how to trunk VLANs across the fiber to the DC for our phone integration. The Cisco guy was talking about a Layer 3 VLAN, or virtual interface, or something like that. Time to do some research.
  • Received one of our modem servers from www.siliconmechanics.com; they’re a systems integrator. Great to do business with. Problem of the day, though, is this: the new server has an Intel SATA controller. XP doesn’t have a native driver (and yes, we’re using XP on the server). With no floppy drive, how do you load XP? Check out www.nliteos.com if you haven’t yet – it’s amazingly easy to build a bootable Windows XP or 2003 CD with your text-mode drivers pre-installed. I’m making a few for each of our custom servers with the RAID controller, NIC, and video drivers pre-loaded. Had the same problem with an HP DL320 G5p server – I stuck in the SmartStart CD and it said, “Sorry, this disk controller is not supported.” What? What a monumental error HP made on that deal. How can they ship a server that doesn’t run SmartStart? Anyway, nLite to the rescue. I downloaded the SATA drivers from HP and built a new W2k3 installer CD and away we went.