RE: IIS Key pairs (how to export an IIS 4.0 self-issued Root CA a nd import into new IIS 4.0 box)

From: Carlos Manuel Lara Avendano (cmlara@bancosantander.com.co)
Date: 04/01/02


To: focus-ms@securityfocus.com
From: "Carlos Manuel Lara Avendano" <cmlara@bancosantander.com.co>
Date: Mon, 1 Apr 2002 14:43:50 -0500


Hi:

here is another procedure "In house" that i use recently to import an
IIS key to an Intel SSL acelerator
that requiere separate keys.

  exporting keys/certs from IIS in a format that can then be imported

  You'll need:
          IIS 4.0 Server w/SSL Enabled
          OpenSSL
          Hex Editor

  Export Key:
          Key Manager -> Key -> Backup Keyfile
          Save as backup.key

  Hex Edit:
          Open backup.key in Hex Editor
          Find first occurance of "private-key", and search back to 30 82
          Delete all before 30 82
          Save as backup_key.bin

          Open backup.key in Hex Editor
          Find first occurance of "certificate" followed by 30 82
          Delete all before 30 82
          Save as backup_cert.bin

   Convert:
          openssl rsa -inform NET -in backup_key.bin -out backup_new.key
          openssl x509 -text -in backup_cert.bin -inform DER -out
  backup_new.crt

  Use:
          backup_new.key is Private Key
          backup_new.crt is Certificate

  Best Regards

"Brian Burrington" <Brian.Burrington@LABONE.com> con fecha 01/04/2002
12:58:15 p.m.

Destinatarios: focus-ms@securityfocus.com
CC:
Asunto: RE: IIS Key pairs (how to export an IIS 4.0 self-issued Root CA a
        nd import into new IIS 4.0 box)

Hello all,

I've had enough requests for this information, that I thought I'd just post
the instructions to the whole list.

This research was conducted a little more than a year ago. The company
that
I worked for at the time had created a simple B2B system utilizing IIS 4.0,
VB Script .ASP, and a Sybase Database (all on the same machine). The
system
(still in use) has a self-issued Root Certificate Authority, against which
it issues client certificates to the end users. These end users are located
throughout the continental U.S., Canada, and the U.K. There are nearly
2000
client certificates issues, currently.

The original system was located off site at one of UUNET's data centers.
Due to a wide variety of reasons including 1) the expense of UUNET
services,
2) the instability of the system provided by UUNET (a seemingly pre-used
installation of NT 4.0), and 3) difficulty we had in supporting the system
the decision was made to build a new system in-house and to transfer all
data and functionality to it.

Because of the large number of already issued client certificates, we
realized that creating a new CA (and subsequently nearly 2000 new client
certificates) was the very last choice we wished to make. Many months were
put into trial and error study of CA export. Unfortunately, talks with
expensive MS tech support yielded nothing.

Please understand that these are the steps that worked for us in our
specific situation, which included custom code for our web site, MS NT 4.0,
and Compaq Proliant hardware. Some of the steps may only have been
necessary for our systems, due to some of our custom code. I make no
claims
for the repeatability of these procedures. Once we solved our problem and
verified that 1) all clients could access their data, and 2) no clients
would be forced to download new client certificates, we stopped research.
No regression testing has been done. Also, I have no idea if these
procedures will work on Windows 2K/IIS 5.0 - though personally, I (and
others) do find many similarities between vers 4 & 5.

I will happily answer questions on this list, as I have a strong desire to
give back to the community, but please understand that personal one-on-one
support of these procedures is, practically speaking, impossible - as there
are many more of you than there are of me. :-)

I welcome you to share these humble suggestions and procedures with
co-workers, friends, relatives, and strangers. However, I do ask that you
do not modify them and that you retain my name in association with them.
Who knows, maybe it will result in a job opportunity down the line? :-)

Lastly, none of this research was conducted by my current employer, so
inquiries sent to them would be fruitless. I ask that you do not bother
them with questions regarding these procedures, as they will only get
confused and/or annoyed. Also, none of the statements made in this e-mail
are opinions, promises, or guarantees implied or otherwise by either myself
or LabOne, Inc.

Sincerely,

Brian Burrington
Sys Admin
LabOne, Inc.

P.S. I have also provided this e-mail as an attached ASCII file, since I'm
aware that some mail systems will butcher the layout.

------------------------------------------------------------------------
Instructions for the Transfer of Self-Issued Root Certificate Authority
from one IIS 4.0 Server to Another
------------------------------------------------------------------------

Step I - Installing the New (Destination) Server

(Note: To prevent automatic infection by Nimda, Code Red 1 & 2, and other
script-based "worms", perform these steps on a network that has no internet
access. You have been warned)

- Install NT 4.0
(NOTE: Do not set up as PDC or BDC. NTFS recommended)
- Install NT SP 3 ONLY (for now)

- Install Internet Explorer 4.01 w/ Service Pack 2, "DO NOT install IE5.0"
(IE 5.x MAY be added after the CA transfer is complete, though I am not
certain of this.)

- Install NT Option Pack (without certificates) using the option "Upgrade
Plus" choosing the Additional Components:
     -MS Script Debugger & -Windows Scripting Host

- Reboot the server and verify all systems and components are functional
(especially Cert Server)

- Finish installing the rest of the server patches, utilities, and
enhancements
(This was well before Nimda and Code Red. You may need to add the latest -
post 2/1/2001 - security updates and patches AFTER the procedures are
complete.)

- (NOTE: There was a small discrepencie in the two copies of documentation.
The original version (written hastily at 4:00 a.m. amidst much rejoicing)
says to apply Service Pack 6a at this time. A later and more detailed
version instructs to apply the SP after Cert Server 2 is installed. I
suggest the latter, but wanted to include as much detailed info as I
could.)

- Reboot the server and verify all systems and components are functional
(especially Cert Server)

- Download the Certificate Server2 from the Microsoft's FTP site (sorry,
but
the URL has changed. -sigh-)

- Unpack the 5 files into their own directory

- Shut down all IIS & Cert Server services

- Open a command prompt and CD to the Certivicate Server2 directory

- ENTER: sysocmgr /I:certmast.inf /n (the first time you run this to
remove previous version)

- Uncheck the box to uninstall the installed Option Pack version of Cert
Server

- Use NT Explorer and delete all the ORIGINAL Cert Server directories

- Purge the Certificate Authority (if you created one)

- Purge all certificates from the registry - manually

- Reboot the server

- When it comes back up, verify that IIS (miunus Cert Server) is working
properly

- Shut off all IIS services

- Go to the command prompt and got to the Certivicate Server2 directory

- ENTER: sysocmgr /I:certmast.inf /n (the second time you run it to
install new version)
(this will open the dialog box allowing you to uninstall the Option pack
version of Cert Server - more
details regarding the installation of Cert Server 2 can be found in it's
included documentation, follow them and complete the install of Cert Server
2)

- Check the box to install the Cert Server2 version of Cert Server
(IMPORTANT: During the install click on the "advanced" button to enable
critical options)

- You MUST type in the identical settings (company, state, business unit,
etc.) as are entered in the self-issued root CA of the ORIGINAL SERVER

- Do NOT start any IIS (or Cert Serve) services or reboot the computer!
(We found that if we rebooted, the import process would fail and we'd have
to start over.)

Step II - Completing the Install of Certificate Server 2 and Transferring
the Original CA to the New Server

NOW - WITHOUT RESTARTING ANY SERVICES OR REBOOTING:
- Check the Services applet and make sure Certificate Server is NOT started

- Open Windows Explorer, go to C:\Winnt\System32\Certsrv\CertEnroll
subdirectory and delete all files.

- go through all the Cert Server subdirectories, and purge all newly
created
Certificates (including certificates specific to your new server and/or
application - no need to do so from the registry)

- Delete all files in C:\InetPub\CertRoot (NOTE: you may have installed
Inetpub in a different location)

- Next, copy in all your original _server_name_ root CA certificates (using
windows explorer, copy the text .crt files from
your backup source to the following 3 locations: \Inetpub\Certroot

\Winnt\System32\Certsrv\certenroll

whatever special location you have designated to store certificates

We had 2 certificates that were important. They were:
     _server_name_ Certificate Authority.crt
     _server_name_ Certificate Authority_Exchange.crt

- Reboot the server

- Open up Microsoft Management Console - select your "default web sight"
right click on it, select properties, then go to the Key Manager

- Click on "Key" and choose "Restore Key from File" - then use the key from
the Original system
(hopefully you haven't forgotten your password for the key)

- Go back to your \Winnt\System32\Certsrv\certenroll directory

- Double-click on the _server_name_ certificate and install it (click on
the
button)

- Click on the button showing the advanced features

- Choose to install it in the authority root

- Reboot the server

You should be done - test away! (and celebrate)

I cannot stress enough the necessity of testing this procedure.
Since you can expore / copy keys from your originating server without
affecting it's functionality (assuming it's in a production environment),
you can easily attempt this procedure on a commodity PC platform. This
will
enable you to try, fail, start over, try, fail, start over, etc. The
process can seem grueling and I heartily recommend taking notes on what
works and doesn't work. Hopefully, these listed procedures will shorten
your research and testing time. If you can get the process to work 3 times
in a row, then I would say that you've got it nailed down for your
particlular situation and you're ready for the production implementation.

Sincerely,

Brian Burrington
Sys Admin
LabOne, Inc.

------------------------------------------------------------------------
End of Instructions
------------------------------------------------------------------------

-----Original Message-----
From: Brian Burrington [mailto:Brian.Burrington@LABONE.com]
Sent: Friday, March 29, 2002 4:35 PM
To: focus-ms@securityfocus.com
Subject: RE: IIS Key pairs

Are you asking about exporting a self-issued Root Certificate Authority
from
one IIS installation to another? I have done this when we built a new
server to replace an old one.

I even documented the procedure because it was "not supported by
Microsoft".

Holler if you want the documentation.

:-)

B.

-----Original Message-----
From: Stratton, Dan [mailto:Dan.Stratton@Workscape.com]
Sent: Friday, March 29, 2002 2:38 PM
To: focus-ms@securityfocus.com
Subject: IIS Key pairs

Hello,

Has any one had any luck with exporting two separate key files from IIS
4 or IIS 5? We need to import both the public and private keys into a
load balancing device. After much searching on the web, it appears that
Microsoft only exports the pair as one file (*.key in IIS4 and PFX
(PKCS12) in IIS5).

Any advice you may have is greatly appreciated.

Thank you!

Dan

This transmission (and any information attached to it) may be confidential
and is intended solely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient or the person
responsible for delivering the transmission to the intended recipient, be
advised that you have received this transmission in error and that any use,
dissemination, forwarding, printing, or copying of this information is
strictly prohibited. If you have received this transmission in error,
please immediately notify LabOne at (800)388-4675.

(See attached file: IIS 4 Root CA Cert Migration.txt)