Dual-Booting McAfee Endpoint Encryption

I've just spent the best part of two days getting my laptop back up and running. I foolishly installed Kubuntu 11.10, which overwrote the MBR and then I could not boot to Windows, which is what I use at work and because the Windows partition was encrypted there was little I could do to get back in.

After a bit of time wasting with the help desk, I decided to bite the bullet and reinstall everything to get back my dual-boot setup, hoping that I had backed up everything of importance.

In essence the process is fairly simple:

1. Install Windows
2. Install Kubuntu (Linux)
3. Ensure that you can boot to both OSs
4. Install McAfee Endpoint Encryption

Once all that is done, I get the Endpoint Encryption logon prompt, before the Grub menu, so that I can now boot to either Windows or Kubuntu.

We use McAfee Endpoint Encryption 5.2 so I don't know whether this will work for other versions.

Today I found this post which provides a good tip on how to back up the MBR, using the trusted DD command in Linux ( and a different (better?) way of doing the dual boot dance with McAfee EE):

dd if=/dev/sda of=/your_usb_drive/safeboot.mbr bs=512 count=1

If only I've read this before I started.

Note to restore MBR copy safeboot.mbr to /boot from Linux and then you'll need to add an entry to the grub menu, see this how-to for instructions.

Negotiate client certificate in IIS 6.0

The ongoing saga of our SSL issues continues. After some help from a kind soul, we got some java code to do mutual authentication against IIS but this wasn’t working either. If you are wondering why we are after some java code, well that is what they are throwing against IIS.

In my opinion, OpenSSL is the ultimate arbiter of all things SSL and OpenSSL was working, so I was a bit miffed to be asked to make some changes, but I do like playing about with computers so I thought I’d give it a go.

The feeling was that IIS implementation of the SSL handshake would not work with Apache’s HTTPClient and thus we needed to change IIS's configuration. It is true that IIS will only ask for the client certificate when the client makes a request, at which point there will be a renegotiation, rather than within the original handshake, but my understanding is that this is a perfectly valid approach, I’ll need to investigate whether this is indeed the case. In other words, IIS does a simple TLS handshake upon connection and then a renegotiation attempt, when an actual request is made to the server. This is simply a client authenticated handshake, that is initiated by the server via making a HelloRequest.

At any rate, I ran a couple of tests against our IIS dev box using OpenSSL, see this post for more details. Edited output from OpenSSL:

CONNECTED(00000003)

>>> TLS 1.0 Handshake [length 006c], ClientHello

    01 ... 00

<<< TLS 1.0 Handshake [length 0051], ServerHello

    02 ..   00

<<< TLS 1.0 Handshake [length 058e], Certificate

    0b ... 41

<<< TLS 1.0 Handshake [length 0004], ServerHelloDone

    0e 00 00 00

>>> TLS 1.0 Handshake [length 0086], ClientKeyExchange

    10 .. d1

>>> TLS 1.0 ChangeCipherSpec [length 0001]

    01

>>> TLS 1.0 Handshake [length 0010], Finished

    14 00 00 0c ae 1d da b8 d4 14 ab ed 03 50 77 a0

<<< TLS 1.0 ChangeCipherSpec [length 0001]

    01

<<< TLS 1.0 Handshake [length 0010], Finished

    14 00 00 0c d6 9b 9b 66 04 5d c6 5d d2 e1 25 7e

---

Certificate chain

 0 s:/C=US/ST=York/L=York/O=/OU=YORK/CN=server.dev.com

   i:/DC=com/DC=dev/CN=TESTAuthority

---

Server certificate

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

subject=/C=US/ST=York/L=York/O=YORK/OU=YORK/CN=server.dev.com

issuer=/DC=com/DC=dev/CN=TESTAuthority

---

No client certificate CA names sent

---

SSL handshake has read 1555 bytes and written 295 bytes

---

New, TLSv1/SSLv3, Cipher is RC4-MD5

Server public key is 1024 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

    Protocol  : TLSv1

    Cipher    : RC4-MD5

    Session-ID: 7C130000B6F9142AD5E179ECCEC696C6F3C3CE4E100B503ABF3477FD3F7AD8B3

    Session-ID-ctx:

    Master-Key: 44EA6B1B1AACCE188E097F3E904838F33361FAC67207B6311CC0477A2CEEFE6D8F2AE7AF338B9537713381D34460FE05

    Key-Arg   : None

    Krb5 Principal: None

    PSK identity: None

    PSK identity hint: None

    Start Time: 1324388318

    Timeout   : 7200 (sec)

    Verify return code: 0 (ok)

---

At this point a request is made to IIS:

GET /home.htm

<<< TLS 1.0 Handshake [length 0004], HelloRequest

    00 00 00 00

>>> TLS 1.0 Handshake [length 007b], ClientHello

    01 ... 00

<<< TLS 1.0 Handshake [length 0069], ServerHello

    02 ...7e

<<< TLS 1.0 Handshake [length 058e], Certificate

    0b ... 41

<<< TLS 1.0 Handshake [length 0c0f], CertificateRequest

    0d ... 79

<<< TLS 1.0 Handshake [length 0004], ServerHelloDone

    0e 00 00 00

>>> TLS 1.0 Handshake [length 09a4], Certificate

    0b ..    d4

>>> TLS 1.0 Handshake [length 0086], ClientKeyExchange

    10 ... 05

>>> TLS 1.0 Handshake [length 0086], CertificateVerify

    0f ... 9b

>>> TLS 1.0 ChangeCipherSpec [length 0001]

    01

>>> TLS 1.0 Handshake [length 0010], Finished

    14 00 00 0c 58 50 80 3d d0 74 f4 52 cb ad ad 50

<<< TLS 1.0 ChangeCipherSpec [length 0001]

    01

<<< TLS 1.0 Handshake [length 0010], Finished

    14 00 00 0c 3e d0 e2 69 96 29 7b 83 16 68 f7 c8

As I mentioned above the renegotiation process is started by the server and then all that follows is a simple client authenticated handshake. Note that the arrows indicate the direction from the server's perspective, so that the bold line means that the server is requesting a Certificate from the client.

This appears to be the problem, but how to solve it? Well, after a little bit of investigation it turns out that it is fairly easy to enable client certificate negotiation on, remembering that I’m using windows 2003. The httpcfg tool is all you need (maybe, see what happens after an iisreset below). This tool is available with the windows support tools package. There are a myriad of options for this tool but in this case we are only interested in a few commands.

List current SSL configuration with:

httpcfg query ssl

IP                      : 0.0.0.0:443

Hash                    : 76c659afffcb906038682de115c2 ddb2af7c113

Guid                    : {4dc3e181-e14b-4a21-b022-59fc669b0914}

CertStoreName           : MY

CertCheckMode           : 0

RevocationFreshnessTime : 0

UrlRetrievalTimeout     : 0

SslCtlIdentifier        :

SslCtlStoreName         :

Flags                   : 0

Note the typo in the hash field, i.e. the certificate thumbprint. For some reason it does not display zeros, so be careful if copying from the console.

Delete the binding, if the return code is not 0 there is a problem:

httpcfg –delete –i 0.0.0.0:443

HttpDeleteServiceConfiguration completed with 0.

Now you can add it again (there must be a better way of doing this?)

httpcfg set ssl -i 0.0.0.0:443 -h 76c659afffcb906038682de115c20ddb2af7c113 -g {4dc3e181-e14b-4a21-b022-59fc669b0914} -c MY -f 2

HttpDeleteServiceConfiguration completed with 0.

You can list current SSL configuration again and see the changes:

httpcfg query ssl

IP                      : 0.0.0.0:443

Hash                    : 76c659afffcb906038682de115c2 ddb2af7c113

Guid                    : {4dc3e181-e14b-4a21-b022-59fc669b0914}

CertStoreName           : MY

CertCheckMode           : 0

RevocationFreshnessTime : 0

UrlRetrievalTimeout     : 0

SslCtlIdentifier        : (null)

SslCtlStoreName         : (null)

Flags                   : 2

Now you can run the same OpenSSL command as above:

CONNECTED(00000003)

>>> TLS 1.0 Handshake [length 006c], ClientHello

    01 .. 00

<<< TLS 1.0 Handshake [length 0051], ServerHello

    02 ..    00

<<< TLS 1.0 Handshake [length 058e], Certificate

    0b ... 41

<<< TLS 1.0 Handshake [length 0c0f], CertificateRequest

    0d ... 79

<<< TLS 1.0 Handshake [length 0004], ServerHelloDone

    0e 00 00 00

>>> TLS 1.0 Handshake [length 09a4], Certificate

    0b .. d4

>>> TLS 1.0 Handshake [length 0086], ClientKeyExchange

    10 ... a4

>>> TLS 1.0 Handshake [length 0086], CertificateVerify

    0f .. 24

>>> TLS 1.0 ChangeCipherSpec [length 0001]

    01

>>> TLS 1.0 Handshake [length 0010], Finished

    14 00 00 0c 66 1d 74 73 26 4c 93 5a 24 e7 97 4d

<<< TLS 1.0 ChangeCipherSpec [length 0001]

    01

<<< TLS 1.0 Handshake [length 0010], Finished

    14 00 00 0c 76 d4 32 92 0f d8 b9 f8 f9 a8 72 b4

---

Certificate chain

 0 s:/C=US/ST=YORK/L=YORK/O=YORK/OU=YORK/CN=server.dev.com

   i:/DC=com/DC=dev/CN=TESTAuthority

---

Server certificate

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

subject=/C=US/ST=YORK/L=YORK/O=YORK/OU=YORK/CN=server.dev.com

issuer=/DC=com/DC=dev/CN=TESTAuthority

---

Acceptable client certificate CA names

/DC=com/DC=dev/CN=TESTAuthority

---

SSL handshake has read 4642 bytes and written 2907 bytes

---

New, TLSv1/SSLv3, Cipher is RC4-MD5

Server public key is 1024 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

    Protocol  : TLSv1

    Cipher    : RC4-MD5

    Session-ID: 4D12000059032A66B9D456537EDB9B0AAFA0D5762F94CED74DC8EC4E8F175B20

    Session-ID-ctx:

    Master-Key: 9C8A4CF2078FCE4B77DC9CD902DEA7B36AA64A7E110F0634F90FEA2D6AD5FA00BFA761C813387A2CBB2CA5683850724A

    Key-Arg   : None

    Krb5 Principal: None

    PSK identity: None

    PSK identity hint: None

    Start Time: 1324388273

    Timeout   : 7200 (sec)

    Verify return code: 0 (ok)

---

The key is the bolded line, the certificate request, which the server now makes during the initial handshake, or the handshake, as there will only be one handshake now. If no certificate is presented by the client, then the server concludes that no client certificate is being used and the handshake finishes successfully. It is worth noting that once a request is made to the server, this request will fail with 403.7.

If IIS is configured to accept, rather than require, client certificates, then CertificateRequest is only made when a certificate is presented to the server.

One little problem though, changes with the httpcfg tool do not appear to be permanent, which means that it is necessary to edit the IIS metabase, which you can find in <WindowsFolder>\system32\inetsrv\metabase.xml, to make them permanent.

Stop IIS and edit the file. I’m editing a website with id 2100412512, so I changed this:

<IIsWebServer  Location ="/LM/W3SVC/2100412512"

                                CertCheckMode="0"

                                SSLCertHash="76c659afffcb906038682de115c20ddb2af7c113"

                                SSLStoreName="MY"

                                SecureBindings=":443:"

                                ServerAutoStart="TRUE"

                                ServerBindings=":8080:"

                                ServerComment="test SSL website"

                >

To:

<IIsWebServer  Location ="/LM/W3SVC/2100412512"

                                CertCheckMode="0"

                                SSLAlwaysNegoClientCert="TRUE"

                                SSLCertHash="76c659afffcb906038682de115c20ddb2af7c113"

                                SSLStoreName="MY"

                                SecureBindings=":443:"

                                ServerAutoStart="TRUE"

                                ServerBindings=":8080:"

                                ServerComment="test SSL website"

                >

Start IIS and run:

httpcfg query ssl

IP                      : 0.0.0.0:443

Hash                    : 76c659afffcb906038682de115c2 ddb2af7c113

Guid                    : {4dc3e181-e14b-4a21-b022-59fc669b0914}

CertStoreName           : MY

CertCheckMode           : 0

RevocationFreshnessTime : 0

UrlRetrievalTimeout     : 0

SslCtlIdentifier        :

SslCtlStoreName         :

Flags                   : 2

SUCCESS

Configuring IFD for MS Dynamics CRM 2011

I've started going through the various training manuals for the MS Dynamics CRM Certification exams and one of the things that I had never done before was to configure an Internet Facing Deployment, so I grabbed Microsoft's white paper and went to work. I am not going to provide a step by step of what I've done, if that's what you are after have a look at this post on the InteractiveWebs blog, I just wanted to comment on the issues that I encountered.

In the white paper it wasn't too clear, I did skim through it rather than read it in detail, that it was geared towards a single server (CRM + ADFS 2.0) setup, so that it had, for me, some unnecessary steps, or quite a lot as for some reason I started using port 444 halfway through, which needless to say did not make life any easier.

I've still not had time to go through everything in detail, I just got it working, but I cannot really understand the terminology, when you configure IFD you have to provide the following:

• Web Application Server Domain
• Organization Web Server Domain
• Discovery Web Service Domain

but these simply point to you CRM Server yet you still need these (I imagine, I've not tried odd values here), which means that you also need to add DNS entries, preferably CNames to make life easier, for it to work.

 

You also need an orgname.mydomain.com DNS entry to actually access you IFD externally, which technically means that you need to buy that domain so that it can be accessed externally, unless you are configuring IFD for the sake of it, like I am.

What the ...., Microsoft?

In the run up to Christmas we seem to have a very light workload and I thought I'd give MS Sharepoint a try to see what all the fuss is about.

I got the ISO from MSDN and after using my newly acquired mad PowerCLI skills to clone a new VM, I ran the Sharepoint installer.

I clicked on the install pre-requisites option and after a few minutes it stopped working, why? because it could not connect to the internet, say what?

You expect an enterprise grade application to have internet access? This is insane, this is the sort of crap that really makes me wish I had nothing to do with Microsoft.

Anyway, you can find all the pre-requisites here, download them and then you can install Sharepoint 2010 SP1, maybe.

What I really don't understand is why they are not contained in the ISO: if they are pre-requisites then they should be in the ISO. It's only the optional pre-requisites, that's a good oxymoron, that should need to be downloaded, but mandatory pre-requisites? 

I sometimes don't understand Microsoft. It seems to bend over backwards to make life easier for everybody, particularly developers, and every so often you get stuff like this, which makes no sense whatsoever.  

Disable NIC in ESX VM using PowerCLI

I was trying to understand how CRLs work in IIS 6.0, see my previous two posts here and here and I was trying to prevent communication between the CA server and the application server. I was having to go into vSphere and modify the settings of the NICs (disconnecting them), which got tiring pretty soon. So, I thought I would try to do it from the ESX console and after a bit of digging I found that it should be doable with the vmware-cmd command, like this:

vmware-cmd myCAserver..vmx disconnectdevice ethernet0

Alas, this was the result:

Traceback (most recent call last):

  File "/usr/bin/vmware-cmd", line 88, in ?

    main()

  File "/usr/bin/vmware-cmd", line 63, in main

    operationName, result = CommandProcessor.Process(host, args)

  File "/usr/lib/vmware/vmware-cmd/CommandProcessor.py", line 11, in Process

    result = operation.DoIt(*processedArgs)

  File "/usr/lib/vmware/vmware-cmd/operations/DeviceOps.py", line 152, in DoIt

    device.SetConnected(False)

AttributeError: 'NoneType' object has no attribute 'SetConnected'

After a extra bit of googleing which failed to come up with a decent answer, I gave up and decided to give PowerCLI a try.

I launched PowerCLI from the start menu and connected to the VI server with:

Connect-VIServer viservername

Once Connected to the vcentre server I got both VMs and stored them in a variable with the following commands:

$CA = Get-VM –Name “myCAServer”

$app = Get-VM –Name “myAppServer”

I checked that this has grabbed the VM that I wanted by simply typing:

$CA

which returns:

Name                 PowerState Num CPUs Memory (MB)
----                 ---------- -------- -----------
myCAServer           PoweredOn  1        1024           

Since both Guests have only one NIC, I got the nic details and stored in a variable for use later:

$CAnic = Get-NetworkAdapter $CA

$appnic = Get-NetworkAdapter $app

Now I can use Set-NetworkAdapter to switch them on or off at will. To turn off the CA Server’s NIC:

$CAnic = Set-NetworkAdapter –NetworkAdapter $CAnic –confirm:$false –connected:$false

And then back on:

$CAnic = Set-NetworkAdapter –NetworkAdapter $CAnic –confirm:$false –connected:$true

I can now check the status with:

$CAnic.ConnectionState

which returns:

         AllowGuestControl                  Connected            StartConnected
         -----------------                  ---------            --------------
                      True                      False                      True

Remember that command completion works pretty well, so you could just type $CAnic. And then keep pressing TAB. Similarly, if you are unsure about the switches for a cmdlet, just type - and then TAB through the options.

It is also possible to pipe commands so that you don't need to use several variables, e.g.

$CAnic = Get-VM -Name "myCAServer" | Get-NetworkAdapter | Set-NetworkAdapter -Connected:$false -confirm:$false

I still use a variable, so that I can easily check the status of the NIC, but it's not necessary, I could have simply used:

 Get-VM -Name "myCAServer" | Get-NetworkAdapter | Set-NetworkAdapter -Connected:$false -confirm:$false

I find that using variables is easier for a beginner such as myself. At any rate, I'm glad I've given PowerCLI a go as it is really good.

CRL checking in IIS 6

It turns out that it is indeed easy peasy to understand how CRLs work in IIS 6.

If the certificate contains a CRL Distribution Point (CDP), IIS will try to contact it and if it can’t, 403.13 is your friend.

Thus CRL checking will always take place in IIS except when:

• Certificates don’t contain a CDP.
• CertCheckMode is set to 1 for that particular website.

Note that if CertCheckMode is not set, IIS takes that to mean enabled and also note that CertCheckMode is set on a website by website basis.

Simple right?

I wish I'd found Saurabh Singh's very informative post before I'd spent half the morning messing about with an application server and a CA server trying to work out what was going on. I'd like to believe that I would have reached the same conclusion by myself and I certainly was close, after a myriad of tests revealed that adding a CRL file to the local computer trust store made absolutely no difference, which is what actually prompted me to have another go at googleing for the an answer, but who knows.

I wonder how IIS 7 deals with CRLs.

Disable CRL Checking in IIS 6

It's been a bit of nightmare today, we've had quite a number of issues, ranging from missing CA certs to firewall issues, with routing issues and DNS issues thrown into the mix for good measure.

One by one we sorted the issues out and we kept getting a 403.13 error. We even got the CRL and followed this, but to now avail.

Unfortunately, we have no control over the firewall, so we are waiting for this to be sorted out but in the mean time I found how to disable CRL checking in IIS 6. You just need to run the trusted adsutil.vbs script from c:\inetpub\adminscripts like this:

cscript adsutil.vbs SET w3svc/<websiteid>/CertCheckMode 1

After setting this, it all started working. To switch CRL checking back on, use this:

cscript adsutil.vbs SET w3svc/<websiteid>/CertCheckMode 0

Now I just need to understand how CRL checking works in IIS, easy peasy.

A simple chat server - client

I was reading this article about how Skype and other VOIP services punch a hole through firewalls and in the second page I was introduced to the netcat command, which can do a lot, but today I just thought I'd talk about using it as a instant chat program.

You'll need two machines, server and client and an open firewall on the port you decide to use.

On server type:

nc -l 10333

On client type:

nc server 10333

Syntax may vary depending on distro, the above works on RHEL.

Anything that is typed in either server or client will be sent to the other party, thus providing you with a primitive instant chat.

Enjoy

The Magic Wand Theory

If you've been working in IT for a long time, like I have, at least it feels like a long time, you probably have experienced the effects of the magic wand theory. This theory could be formulated like this: 

There is an employee/consultant that has sufficient knowledge of a system and/or technology that he or she will be able to fix any issue with said system or technology as if by waving a magic wand.

At least management seem to think that this theory holds true.

I feel very strongly about the magic wand theory as I've been on both sides of the theory: The Apprentice and The Wizard.

The Apprentice

I joined my current company fresh out of university and consequently there were massive gaps in my knowledge, I was the Apprentice to the consultant Wizard. We ran into several issues during the first weeks of live running for an application and time and time again the consultant would repeat the troubleshooting steps that I had carried out. Sometimes he fixed the issue, sometimes he didn't, but the reality that I was an apprentice meant that whenever there was something unexplained or that I could not explain satisfactorily, The wizard would be called. Ordinarily he would be just as stumped as I was and it was through collaboration and analysis that we managed to sort the issues out. Yet the perception that I was still an apprentice never quite faded.

The Wizard

I only became a wizard through the process of acquiring an apprentice, i.e. somebody with less experience than me. In a similar fashion as when I was an apprentice, my apprentice's opinions were ignored and almost always required my confirmation, even when, as was the case most of the times, I was in agreement with my apprentice, but such is life in the world of IT support.

It is quite revealing how disconnected middle management is from upper management on this issue. The former is an ardent supporter of the magic wand theory and can be quite willing to provide perks and salary increases (within their limited power) to keep wizards from leaving, whereas the latter just cares about the bottom line and is pushing for off shoring as if it were going out of fashion.

Even More OpenSSL - Client Certificates

In these posts (1, 2), I discussed using OpenSSL as a simple SSL client to help troubleshoot SSL connections. I did not make any mention of client certificates because, to be honest, we hadn't got that far in our testing, but now that we have and, surprisingly enough, ran into trouble I thought I would discuss using client certificates with OpenSSL. 

In essence this is the command you need to run:

openssl s_client -CApath <pathtoCAcerts> -cert <clientcert> -key <clientcertkey> -pass <keypassphrase> -connect <serveripaddress>:443

where you can substitute CApath for CAfile if you only care about a single CA. The key and pass switches are optional, depending on your client certificate, e.g. if your client certificate has the key in the same file and no pass phrase you can omit them both.

openssl s_client -CAfile <pathtoCAcert> -cert <clientcert> -connect <serveripaddress>:443

You'll get something like this, showing only an extract from the response:

..
..
..
..
SSL handshake has read 1548 bytes and written 295 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
    Session-ID: 92220000BD6498AD833C46B2F3660E6E8131F1233EF25B59A68311394CCBDB8F
    Session-ID-ctx:
    Master-Key: 717135CF0F753CAA1CE67A2713356A05D5C4AB32EE71AAA39F09C1696F865B727D36ACECC9CF8529A0A61C036E1607C7
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1323622751
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

You now can try to communicate with the server, e.g. try to get a page:

GET /home.htm

This should return the contents of home.htm. In actual fact you get the whole server response, not just the page, as is to be expected:

depth=1 DC = com, DC = dev, CN = TESTAuthority
verify return:1
depth=0 C = US, ST = York, L = York, O = York, OU = York, CN = server.dev.com
verify return:1
read R BLOCK
HTTP/1.1 200 OK
Date: Sun, 11 Dec 2011 17:15:55 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private, max-age=0
Content-Type: text/html; charset=utf-8
Content-Length: 310
..
..
..
..

If you try without the client cert (e.g. openssl s_client -CAfile <pathtoCAcert> -connect <serveripaddress>:443), you will get an error page back (at least from IIS you do), when you try to to communicate with the server (e.g. GET /home.htm). Extract from response:

<h2>HTTP Error 403.7 - Forbidden: SSL client certificate is required.<br>Internet Information Services (IIS)</h2>

Business Closures in MS Dynamics CRM

We had an incident last week, where a user complained of not being able to create business closures, specifically of a business closure for Christmas. When we had a look at the system, the business closure was there. Since there was a bit of lag between the incident being raised and it getting to us, we simply closed it assuming that it was a temporary glitch, the eternal hope of the support professional (I use professional in the loosest sense of the word), alas it wasn’t.

The incident came back and this is when we realized that there is no way of telling when or by whom had a business closure been created. A scan of the database tables did not help and then I had a flash of inspiration so looked at the calendarbase table and sure enough there is a calendar whose name is 'Business Closure Calendar' and each business closure is a calendarrule linked to this calendar, which means that you can use this query to retrieve any information about all business closures:

Select * from calendarrule where calendarid in (select calendarid from calendar where name='Business Closure Calendar')

This allowed us to discover a design fault in the security roles that allows one type of users to create them but crucially not the right type, god knows how it was missed during system testing.

I just had a look at one of our development boxes and this also applies to MS Dynamics CRM 2011.

Install MS Dynamics CRM 2011 to an Active-Active MS SQL Server Failover Cluster using ESX 4.0

The fifth post of the series describes how to install Microsoft Dynamics CRM 2011 to both SQL Server failover clusters. Previous posts in the series can be found here: 1, 2, 3 & 4.

I have created a couple of VMs, CRM2011APPA & CRM2011APPB, to use as MS Dynamics CRM 2011 Application Servers.

In this configuration you will need at least two application servers per SQL Server failover cluster, as there is little point in having resilience only in one side of the fence, as it were, but for the purposes of this demo two VMs will suffice.

There are quite a few pre-requisites that need to be fulfilled before MS Dynamics CRM 2011 can be installed:

• You need to install two instances, SSRSA & SSRSB, of MS SQL Server Reporting Server 2008, SSRS henceforth. You can install them in separate Guests or you can reuse your SQL Server failover cluster servers, which is what I have done. You can scale out the SSRS deployment to provide high availability. Note that it would seem that it is not possible to create two scaled-out deployments on the SQL Server failover cluster servers, so I have gone for single-server SSRS deployments. (I know, I know) 
• You will need to create at least an OU on your domain to install MS Dynamics CRM 2011, I have actually created two (HACRM2011A & HACRM2011B): One for each deployment. The installer account(s) will need full control of these OUs (it doesn’t really, but it makes life easier that way).
• You will need at least a new service account to run MS Dynamics CRM 2011, and it is recommended that the sandbox service is run under a separate account too, so make that two accounts or four (two per deployment). Arguably you could re-use the SQL Server failover cluster account if all you are going to do with the cluster is run MS Dynamics CRM 2011, which is what I have done, so the service accounts are sqlcluster2k8a & sqlcluster2k8b.

I think that using a single service account per deployment is acceptable. In essence if the cluster goes down, so does your application, which means that having a separate account will not protect you. If you separate the accounts and the MS Dynamics CRM 2011 service account goes, you still don't have an application, so you have not really gained anything. All of this assumes that you are not using the cluster for some other application.

I shall now describe how to install both instances SSRS so that they can be used by MS Dynamics CRM 2011.

You need to create a couple of service accounts, ssrs2k8a & ssrs2k8b, to run each instance of SSRS, but unlike in SSRS 2005, you do not need IIS.

From the first cluster node, win2k8a, run setup.exe, which will start the SQL Server Installation Center wizard. From the installation tab, select New SQL Server stand-alone installation or add features to an existing installation, which you should know by now, will launch a wizard to check the setup support files and ask you to install them, even if you have installed them before. After many wizards you will arrive at the SQL Server 2008 Setup wizard:

• On the Installation Type tab: select Perform a new installation of SQL Server 2008.
• On the Feature Selection tab: select Reporting Services.
• On the Instance Configuration tab: use SSRSA as the name of the instance.
• On the Server Configuration tab: set the user account and password (ssrs2k8a)
• On the Installation Rules tab: select install but not configure

Once the installation has completed, you need to configure it. Run the Reporting Service Configuration Manager from Start -> All Programs -> Microsoft SQL Server 2008 -> Connfiguration Tools -> Reporting Service Configuration Manager.

• Connect to the SSRSA instance.
• On the Web Service Url tab: accept the defaults by pressing apply.
• On the Database tab: click Change Database which will launch the Report Server Database Configuration Wizard.
• On the Action tab: select Create a new report server database.
• On the Database Server tab: set Server Name to sql2k8a\sql2k8a and ensure test connection has succeeded. You will need to use your hostname\instancename.
• On the Report Manager URL tab: press apply, if you go to the next tab and come back to this tab, you’ll now see the advanced button is enabled.
• On the Encryption Keys tab: ensure that you backup the symmetric key, by pressing backup. A great improvement from SQL Server 2005 is that you are now prompted for a confirmation password.
• On the Web Service URL tab, double click on the URL, which should take you to the report server website.

The installation process for the second node is identical to the first node, except for the need to use a different instance name, SSRSB and a different user account, ssrs2k8b.

Once the installation has completed, you need to configure it. Run the Reporting Service Configuration Manager from Start -> All Programs -> Microsoft SQL Server 2008 -> Connfiguration Tools -> Reporting Service Configuration Manager.

• Connect to the SSRSB instance.
• On the Web Service Url tab: accept the defaults by pressing apply.
• On the Database tab: click Change Database which will launch the Report Server Database Configuration Wizard.
• On the Action tab: select Create a new report server database.
• On the Database Server tab: set Server Name to sql2k8b\sql2k8b and ensure test connection has succeeded. You will need to use your hostname\instancename.
• On the Report Manager URL tab: press apply, if you go to the next tab and come back to this tab, you’ll now see the advanced button is enabled.
• On the Encryption Keys tab: ensure that you backup the symmetric key, by pressing backup. A great improvement from SQL Server 2005 is that you are now prompted for a confirmation password.
• On the Web Service URL tab, double click on the URL, which should take you to the report server website.

At this point you are ready to start the MS Dynamics CRM 2011 install. However, neither deployment has been scaled out, so this is a single point of failure. I guess this is another one that I'll need to investigate.

From the first application server, CRM2011APPA, Run splash.exe and select Install Dynamics CRM Server, which will launch the Microsoft Dynamics CRM Setup wizard to install MS Dynamics CRM 2011:

• On the Install Required Components screen: click install. Once the .NET framework 4 has installed you will need to reboot and launch the wizard again. When you get back to this screen, click install to finish the installation of the required components.
• On the Specify Deployment Options screen: enter sql2k8a\sql2k8a (your first SQL Server failover cluster hostname\instance name)
• On the Select the organization unit screen: select the HACRM2011A OU.
• On the Specify Service Accounts screen: you should use a separate account for the Sandbox Processing Service, this is a best practice, which I have not followed. I have used sqlcluser2k8a for all services.
• On the Specify Reporting Service Server screen: ensure that you type the correct url: http://win2k8a/ReportServer_SSRSA

As if by magic the necessary features have been added to the OS, a little bit cheeky of Microsoft perhaps? At any rate, you can now access your new instance of MS Dynamics CRM 2011 on http://localhost.

From the second application server, CRM2011APPB, repeat the process changing the instance (sql2k8b\sql2k8b), OU(HACRM2011B), service account(sqlcluster2k8b) and ssrs deployment (http://win2k8b/ReportServer_SSRSB)

In order to complete the installation you need to install Microsoft Dynamics CRM Reporting Extensions to each SSRS instance.

From node 1, win2k8a, Run Splash.exe and select Install Microsoft Dynamics CRM Reporting Extensions.

• You need to install .NET framework 4, which means that a reboot will be needed.
• On the Specify Configuration Database Server screen: select sql2k8a\sql2k8a
• On the Specify SSRS instance name screen: select SSRSA

From node 2, win2k8b, repeat the same steps to install Microsoft Dynamics CRM Reporting Extensions to SSRSB.

You have now two MS Dynamics CRM 2011 deployments on a active-active SQL Server failover cluster configuration.

Active-Active MS SQL Server Failover Cluster using ESX 4.0 - part 4

The fourth post in this series, without a doubt the shortest, describes how to install the second SQL Server 2008 failover cluster, SQL2K8B. Other posts in the series can be found here: 1, 2 & 3.

The process is fairly similar to the process described in the previous post to install the first SQL Server 2008 failover cluster, SQL2K8A. 

You need to make sure that all the cluster resources are in Node 1 and then start the installer by launching Setup.exe. Run the gauntlet of wizards until you get to the Install a SQL Server failover cluster wizard:

• On the Instance Configuration tab: set the sql server network name and the InstanceID to: SQL2K8B.
• On the Cluster Resource Group tab: accept the default: SQL Server (SQL2K8B).
• On the Cluster Disk Selection tab: select the remaining Disk (Cluster Disk 3).

• On the Cluster Network Configuration tab: set the IP address to 10.168.20.244, namely the IP address for SQL2k8b.

• On the Server Configuration tab: use the service account for the second cluster (sqlcluster2k8b).

Once completed  you can check a successful install by running the Failover Cluster Manager.

Figure 4.1 Failover Cluster Manager console display both SQL Server failover groups

Now, you can repeat the same process to add the second node to the second cluster.

You should now repeat the same tests as in part 3. When finished, remember to failover each service to a different node, so that you have a true active-active SQL Server failover cluster, see Figure 4.2 below.

Figure 4.2 Failover Cluster Manager displaying Active-Active configuration.

You now have an active-active SQL Server 2008 failover cluster, it doesn't do much, or anything really, but we'll soon give it something to do. Stay tuned for the fifth part of the series.

Active-Active MS SQL Server Failover Cluster using ESX 4.0 - part 3

In the first part of this series, I discussed how to set up the ESX Guests to enable Active-Active failover clustering. In the second part of this series, I discussed how to set up a Windows Failover Cluster in Windows 2008 R2. The third part in this series describes how to install the first SQL Server 2008 failover cluster, SQL2K8A of the Active-Active SQL Server 2008 failover cluster.

You need to create a couple of service accounts in your domain to run the SQL Server and associated services. If you are not going to use service SIDs then you will also need a couple of domain groups. I have decided to use service SIDS. This option is only available for Windows 2008 and thus I have only created two domain user accounts:

• SQLCluster2K8a.
• SQLCluster2K8b. 

You can add this account to the local administrator group to allow you to administer the servers, but it is not necessary.

The rationale behind this decision, to use two service accounts, is: to prevent an account lock-out from taking both of your SQL failover clusters down. It is not a requirement and thus you can simply use a single account to run both SQL failover clusters, as indeed I have done for this demonstration (Talk about do as I say, not as I do).

In order to prevent potential issues compatibility issues it is necessary to slipstream SP1 into the installation media. You can check this link for details on how to do this. Please note, that it is not necessary to slipstream all architectures as the link suggests, you just need to do the architecture that you are using. 

Run Setup.exe and from the Installation tab, select New SQL Server failover cluster installation, which will launch a wizard that will guide you through the installation process. The wizard will check the server for its suitability as a failover cluster and it will then install the setup support files. The installation wizard proper will run after this.

On the Setup Rules Support tab, I encountered a few warnings:

1. Distributed Transaction Coordinator (MSDTC) Clustered
2. Microsoft Cluster Service (MSCS) cluster verification warnings
3. Microsoft .NET Application Security
4. Network Binding order

Which were dealt with like this:

1. I don’t think MS Dynamics CRM  2011 uses MSDTC, so I’m not too bothered about this warning, however, see this link for details of how to cluster the MSDTC service.
2. I ran a cluster validation test and the warning went away.
3. Guests I'm using don’t have access to the internet so this is to be expected.
4. In theory, following this KB should have fixed the issue, alas the warning continues to appear and I'm not sure why. The binding order is definitely correct on both nodes.

See Figure 3.1 to see the selections I made on the Feature Selection tab:

Figure 3.1 Selected Features for first node of SQL2K8A failover cluster.

You might already have the management tools installed somewhere else, but I've always found it useful to have them in the actual server.

• On the Instance Configuration tab: I set the SQL Server Network name and the instance name so that it matches the SQL Cluster DNS A Record, namely SQL2K8A.
• On the Cluster Disk Selection tab: make sure that you only select one of the Cluster Disks, you'll need the other for the second SQL failover cluster.
• On the Cluster Network Configuration tab: Deselect use DHCP and set the IP Address for SQL2K8A,   10.168.20.243 in this case.
• On the Database Engine Configuration tab, add the service account (SQLCluster2K8A) and your user.

Once the installation completes, you can check that it has successfully created a new cluster service (Resource group in Windows 2003 parlance) by running the Failover Cluster Manager, see figure 3.2  Do not try to failover this group yet, as it has not been installed on the passive node.

Figure 3.2 Failover Cluster Manager displaying the components of the first SQL Server failover cluster (SQL2K8A).

The procedure for installing the second node of the SQL Server failover cluster is fairly similar to installing the first node. Assuming that you have slipstreamed SP1 for this node you can start the installation by running Setup.exe and going through the wizard, however, rather than selecting New SQL Server failover cluster installation from the Installation tab, you need to select Add node to a SQL Server failover cluster. This will launch a wizard, that will run some checks and then it will launch another wizard that will install the setup support files before finally launching the Add a Failover Cluster Node wizard.

I encountered an error related to .NET Framework before even launching the first wizard, which did not occur in node 1. I’m not sure what the source of this error is, but since there is an easy workaround, which is to add the .NET Framework 3.5.1 Feature, that is what I did. All Features can be installed from Server Manager. Note that the .NET Framework 3.5.1 Feature will require you to install some dependencies.

On the Cluster Node Configuration tab, ensure that you use the same SQL Server instance as for node 1, in practice this should mean to simply accept the defaults.

Continue the Wizard until it finishes the installation. You now have, assuming that you haven’t encountered any errors, a SQL Server failover cluster, congratulations.

It is advisable to test the reliability of the cluster at this stage. I would suggest that you run the following tests (these are similar tests to those in part 2):

1. Turn off Active node. All cluster resources should failover to the passive node.
2. From Failover Cluster Manager move SQL Service to passive node.
3. From ESX, switch off the public network on the active node. The cluster should fail over to the passive node. When I tried this, it did not work. I’ll need to investigate

This concludes part three of the series, in the fourth part I will show how to install the second SQL failover cluster.

Manual Failover of Cluster Groups

As part of my series in Active-Active clustering, first post here, I was trying to failover the cluster disks to take a screenshot and it turns out that it isn’t possible to failover a group from one node to the next using Cluadmin.msc

So after a quick google search I found this:

cluster group "cluster group" /move:<nodehostname>

Active-Active MS SQL Server Failover Cluster using ESX 4.0 - part 2

In the second part of this series, I will show how to install and configure a failover cluster in Windows 2008.  Following from the previous post, I’m going to assume that you have already installed Windows 2008 to both nodes.

In order to make your life easier it would be a good idea to name the network cards in Windows, public and private. I’ve given 192.168.168.1 & 192.168.168.3 respectively to the private network NICs, whereas the public network NICs have been given an IP address in our development network (10.168.20.240 & 10.168.20.241).

An active-active cluster needs three A Name Records in your DNS server:

• One Record for the Windows cluster (win2k8cluster -> 10.168.20.242).
• Two Records for each “SQL cluster” sql2k8a & sql2k8b -> 10.168.20.243 & 10.168.20.244 respectively.

You can add the LUNs (SAN Volumes) to Windows. Run the Computer Management console, from Start -> Run  -> compmgmt.msc, and select Disk Management:

1. Right click on disk 1 and select Online. Ensure all disks are selected and click OK.
2. Right click on disk 1 and click Initialize Disk. 
3. Right click on disk 1 and select New Simple Volume. Follow the Wizard. Suggest that you provide a Volume Label (e.g. Data A).

Repeat steps 2 & 3 for the other disks.

Figure 2.1 Computer Management Console showing Quorum Disk and two Data disks

In contrast to Windows 2003, where failover clustering is installed by default, in Windows 2008 you need to add the failover clustering feature, which you can do in Server Manager. Thus, from Server Manager:

1. Click Features.
2. Click Add Features.
3. Select Failover Clustering.
4. Click Install.

You can now start the cluster administration console or Failover Cluster Manager, from Start -> Run -> cluadmin.msc. Note that cluadmin does not appear to work as it did in Windows 2003, you will need to type cluadmin.msc.

Figure 2.2 Failover Cluster Manager Console

You can now create a new cluster, by clicking on create a new cluster. This will launch a wizard that will guide you through the process of creating a new cluster.

On Step 3, run through the validation tests. As I mentioned in the first post of this series, the firewall test failed. This is the error message:

Validate Windows Firewall Configuration
Validate that the Windows Firewall is properly configured to allow failover cluster network communication.
Validating that Windows Firewall is properly configured to allow failover cluster network communication.
An error occurred while executing the test.
There was an error verifying the firewall configuration.
An item with the same key has already been added.

This is an issue with Guest (VM) cloning. I got around it by adding a couple more NICs to the second node, so that it now has 4 NICs, with the first two disabled, not very elegant but it does the trick.

Make sure that you change the ip addresses on NICs 1 & 2 just in case they accidentally get enabled as it could be a barrel of laughs if they inadvertently do get enabled.

On Step 4, enter your cluster name and make sure that you only enable the public NIC for administering the cluster. You need to ensure that the IP address assigned to the public network (10.0.0.0/8) is the IP address of the cluster name.

Figure 2.3 Create Cluster Wizard. Add an Access point for administering the cluster

Follow the wizard until the Cluster is created.

It is advisable to test the reliability of the cluster at this stage. I would suggest that you run the following tests:

1. Turn off Active node. The cluster resources should failover to the passive node.
2. Failover Cluster Group. This should move the cluster group to the passive node. This can be accomplished with the following command (needs to be run as an Administrator): Cluster group “Cluster Group” /move:wink2kb
3. From ESX, switch off the public network on the active node. The cluster should fail over to the passive node. When I tried this, it did not work. I’ll need to investigate.

This concludes part two of the series, in the third part I will show how to install the first SQL Server failover cluster.

Active-Active MS SQL Server Failover Cluster using ESX 4.0 - part 1

Microsoft SQL Server does not support scale out deployments, which means that scaling out has to be built-in into the design of the application. The simplest way of doing this is by splitting data across two or more databases and running an active-active cluster. This is a series of posts that will show you how to do deploy such a system.  I will then use the active-active cluster to deploy two separate organizations of Microsoft Dynamics CRM 2011.

VMware has a pretty good document detailing how to create the necessary Guests (VMs) to run a successful Microsoft failover cluster here. In my opinion, there is no point in running a failover cluster from the same host, you could argue that there is no point in looking for database performance in ESX but that's a different point. At any rate, I am using a set up that allows the guests to be on different hosts and these are the pre-requisites for the hosts:

• Two physical network adapters dedicated to the MSCS cluster and to the public and private networks.
• One physical network adapter dedicated to the service console (ESX hosts) or the VMkernel (ESXi hosts).
• Fibre Channel (FC) SAN. Shared storage must be on an FC SAN.
• RDM in physical compatibility (pass-through) or virtual compatibility (non-pass-through) mode. VMware recommends physical compatibility mode. The cluster cannot use virtual disks for shared storage. Failover clustering with Windows Server 2008 is not supported with virtual compatibility mode (nonpass-through) RDMs

If you have all that, then let's move on, otherwise you could have a look at VMWare's document and follow the single host section.

I created three volumes (LUNs) in our SAN array, two for Data (one for each resource group, more on this later) and another one for the Quorum disk. The quorum disk can be small, in production (Win2k3) we run with 0.5 GB, but here I gave it 1 GB and 20 GB for the Data disks.

I tried to save time and simply cloned an already existing Guest with Windows 2008 R2 installed but it turns out that this is not a very good idea, have a look at this post. In essence, the network cards get the same Guid and this creates problems. I got around this by adding a couple of extra NICs to the second Guest, but there must be a more elegant way of doing this. I'll have to investigate.

Anyway, at this point you should have: three LUNs in your SAN array that are accessible to your Hosts, two Guests with at least two NICs and a hard drive for the OS.

Before you start, you need to ensure that the LUNs you created in the SAN array are available to the Hosts, you can do this in vSphere or through the console. (Not sure how to do it in the console, so I’ll have to investigate that as well).

In vSphere, from Home -> Inventory -> Datastores, Right Click on the Datacentre containing your Hosts -> Select Rescan for Datastores…-> Click OK.

1.1 vSphere Datastores View.

You can check that the scan has successfully found the new LUNs by trying to add a new store. Right Click on you datacentre -> Add Datastore -> Select your Host -> Select Disk/LUN -> You should now see your LUNs, see figure 1.2.

1.2 Example LUN.

Do Not Add the LUN here, just click cancel, this is a simple test to check that the LUNs are visible to the Hosts.

Note that from the console, you can just check the output of: fdisk -l

You are finally ready to start. In vSphere from Home -> Inventory -> VMs and Templates, Right Click on Node 1 (win2k8a in my example) and select Edit Settings:

1.3 Node1 (win2k8a) original settings.

1.  Click Add.
2. Select Hard Disk.
3. Select Raw Mappings Device.
4. Select the first LUN you want to use.
5. Select Store with Virtual Machine.
6. Select Physical Compatibility.
7. Set Virtual Device Node to SCSI (1:0).
8. Click Finish.

In step 6 I’ve selected Physical Compatibility, because I’m not fussed about taking snapshots as I’m running this as a test, this might not be your case, so you might want to set it to Virtual Compatibility, your call.

In Step 7, it is important that you select a different controller from the controller where your OS disk is. Normally, setting to SCSI (1:0) should be ok. If done correctly a new controller would have been added by ESX.

Repeat steps 1 to 8 for the other two LUNs. Note that you’ll need to use different virtual device nodes in step 7, e.g. 1:1 & 1:2.

Ensure that you set the SCSI controller 1 SCSI Bus Sharing to Physical, as per figure 1.4.

1.4 Second Controller SCSI Bus Sharing settings.

Let’s now move to the second node. Right Click Node 2 (win2k8b in my example) and select Edit Settings:

1. Click Add.
2. Select Hard Disk.
3. Select Use an existing virtual disk.
4. Browse to the datastore holding node 1 and in the directory for node 1, select the first LUN disk.
5. Set Virtual Device Node to SCSCI (1:0).
6. Click Finish.

In step 4, you should add the disks in the same order, so that they map onto each other. Not sure if this is needed, but it makes, kind of, sense.

In Step 5, it is important that you select a different controller from the controller where your OS disk is. Normally, setting to SCSI (1:0) should be ok. If done correctly a new controller would have been added by ESX.

Ensure that you set the SCSI controller 1  SCSI Bus Sharing to Physical, see figure 1.4.

This pretty much concludes the ESX setup and part one of this series. In the next post, I'll cover how to install failover clustering.

A gift for all seasons

Two non-IT related posts in a row, what is going on?

From here.

Although I try to keep this blog about IT related issues and chiefly technical issues at that, I thought I'd share the most poignant statement I've read in a while by a user called stuart downie in comments section of this article about the rich on the Beeb:

Define rich. Until I lost my wife of 47 years last year I considered myself rich. Not in the financial sense but in personal happiness and contentment. I live on around £16,000 a year, have savings and no mortgage so compared to a lot of people I am rich but compared to how I felt before my widowhood I feel definitely poorer.

It looks like I've got a bit of dust in my eyes.

More OpenSSL

In this post, I stated that the errors, see below in red, were due to the linux server not trusting the TESTAuthority CA, which is true and false. It's true in the strictest sense of the word, it's false in the sense that unlike Windows, Linux does not have a central repository for certificates and thus the concept of a Linux server trusting a CA is not quite correct.

CONNECTED(00000003)
depth=0 C = US, ST = York, L = York, O = York, OU = York, CN = crmdevbox.dev.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = York, L = York, O = York, OU = York, CN = crmdevbox.dev.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = US, ST = York, L = York, O = York, OU = York, CN = crmdevbox.dev.com
verify error:num=21:unable to verify the first certificate
verify return:1

Since Linux does not have a central certificate repository we need to pass the CA certificate file to openssl, which we can do with the following command (Note that there is a -CApath switch to pass a directory rather than a single file, in case you want to store multiple CAs in the same place.):

openssl s_client -CAfile testauth.cer -connect server.dev.com:443

CONNECTED(00000003)
---
Certificate chain
 0 s:/C=US/ST=Yorkshire/L=Yorkshire/O=PHP/OU=PHP/CN=server.dev.com
   i:/DC=com/DC=dev/CN=TESTAuthority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFgDCCBGigAwIBAgIKIkXHKgAAAAAAJzANBgkqhkiG9w0BAQUFADBCMRMwEQYK
CZImiZPyLGQBGRYDY29tMRMwEQYKCZImiZPyLGQBGRYDZGV2MRYwFAYDVQQDEw1U
RVNUQXV0aG9yaXR5MB4XDTExMTAyNTA4NTUwOFoXDTEzMTAyNDA4NTUwOFowajEL
MAkGA1UEBhMCVVMxEjAQBgNVBAgTCVlvcmtzaGlyZTESMBAGA1UEBxMJU2hlZmZp
ZWxkMQswCQYDVQQKEwGIUDELMArGA1UECxMCSFAxGTAXBgNVBAMTEGRoejMwNzAx
LmRldi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANNYoEklD7Rgnoq0
Ld1+YkKNVcMy9CLb40kmQ0E5f+7SXPDMqNS12yk81k21PQoioOVPSKG2+pAls/vw
QhbjMBeRXeYkrH6V5+nuBYogRVZil0xMeK5+lOJYwig+rHkd5bo8OU/ep+m0VaPj
k2k9+Ns3ZZ1FwlRf+s0KiT1iKVY1AgMBAAGjggLSMIICzjALBgNVHQ8EBAMCBaAw
RAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA
MAcGBSsOAwIHMAoGCCqGSIb3DQMHMBMGA1UdJQQMMAoGCCsGAQUFBwMBMB0GA1Ud
DgQWBBS6N5Bqj8MOTu9CmsXJXcE+sWRDlDAfBgNVHSMEGDAWgBQiuWOMgDSyXO0d
pdlFswWLTcSM+TCB9gYDVR0fBIHuMIHrMIHooIHloIHihoGtbGRhcDovLy9DTj1U
RVNUQXV0aG9yaXR5LENOPW1hcnMsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNl
cnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZGV2LERDPWNv
bT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JM
RGlzdHJpYnV0aW9uUG9pbnSGMGh0dHA6Ly9tYXJzLmRldi5jb20vQ2VydEVucm9s
bC9URVNUQXV0aG9yaXR5LmNybDCCAQYGCCsGAQUFBwEBBIH5MIH2MIGoBggrBgEF
BQcwAoaBm2xkYXA6Ly8vQ049VEVTVEF1dGhvcml0eSxDTj1BSUEsQ049UHVibGlj
JTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE
Qz1kZXYsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0
aWZpY2F0aW9uQXV0aG9yaXR5MEkGCCsGAQUFBzAChj1odHRwOi8vbWFycy5kZXYu
Y29tL0NlcnRFbnJvbGwvbWFycy5kZXYuY29tX1RFU1RBdXRob3JpdHkuY3J0MCEG
CSsGAQQBgjcUAgQUHhIAVwBlAGIAUwBlAHIAdgBlAHIwDQYJKoZIhvcNAQEFBQAD
ggEBAKPrAW4nxI8AaNWpWHGnEHsUBy9C9jFEVLLXxP7jyawmfEgcBBpl+osxH1hG
FSFxYRa5ZVMhj6wMBMHlleftDZ7y5TunKFkOMqHhB027/SmYoqWw/XyWJxW8/EUq
9i3L5Aw1PV+/oF6Nm05VehXRlXF0ngHcwC4EYFCjt4R+/f7prMZHdvIZUq9VhtcV
VHdOl2NE7QizXdebrlyU5cIoS98XySgDuSjGeIOYY/z03jFghKv62qK5ituqQWYY
S17m516w5fSebBYhVfL5YZoCg5OXo346iZU320a6i5dZWHDDq89GkNp3i8aPxSZL
GyHRoPJzDBzo6WR+212a4j3zTEE=
-----END CERTIFICATE-----
subject=/C=US/ST=Yorkshire/L=Yorkshire/O=PHP/OU=PHP/CN=server.dev.com
issuer=/DC=com/DC=dev/CN=TESTAuthority
---
No client certificate CA names sent
---
SSL handshake has read 1548 bytes and written 295 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
    Session-ID: D0210000497E9440E880E5360922751D08D60E7A480423FED6A6DCD78F88F9CF
    Session-ID-ctx:
    Master-Key: 350CEA4DCCC35DE78660106649A61B31EE78716BDDBDC7AF3EC1FF53C0C9885DB7529CC3854EA88881C73C596672570B
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1322744645
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

No complaints about certificates now.:)