ads

Style6

Style3[OneLeft]

Style3[OneRight]

Style4

Style5[ImagesOnly]

Style2

Fix IKEv2 Mobile Scripts on IOS10

Problem:  

Pre-existing IKEv2 VPN mobile configuration scripts do not work with new iPhones.  The script installs the VPN but connection attempts fail.

iPhone7 does not connect to the IKEv2 VPN.  However, older iPhones running IOS8 and IOS9 continues to connect.

Solution:

Update the Mac OS and Apple Configurator 2 software.  Create a new mobile config after software updates are complete.

Explanation:  

IOS 10 cannot connect to IKEv2 VPNs using mobile scripts designed for IOS 8 & 9.

Additional Information:

http://www.stevenjordan.net/2016/11/mobile-config-gui.html

http://www.stevenjordan.net/2016/11/mdm-cert-enrollment.html

http://www.stevenjordan.net/2016/09/harden-rras-ikev2.html


MDM Cert Enrollment

Task:

How to manually request and enroll certificates for BYOD devices with Windows CA server.

Background:

Automated mobile device management (MDM)  (e.g., Microsoft Workplace-Join,) provides a secure method for device key management.  However, rolling out the right MDM solution can be a serious undertaking.  It may be overkill for some organizations.

This article covers device key-management for special use situations.  It provides instructions on how to manually generate device (e.g., iPhone) certificates for mutual authentication (e.g., IKEv2 VPNs).

Assumptions:

Solution:

Step 1:  Request the device certificate from from any workstation:

  • Start → MMC → File → Add Snap-In:  Add Certificates - Current User
  • Certificates → Current User →  Personal → Certificates → All Tasks → Request New Certificate


Step 2:  Complete the Certificate Enrollment Wizard:                 

  • Select Policy: No changes.  Click Next.
  • → Request Certificates:  User Device Auth → Click Details →  Click Properties.
  • → Certificate Properties:      

        →  [Subject Tab]
                  Subject Name:
                       Common Name (CN) = user_device@stevenjordan.net;  add.
                       Email = user_email@stevenjordan.net;  add. Given Name:  First and last name; add.
                  Alternative Name:
                        DNS = user_device@stevenjordan.net; add. N.B., DNS must match Full CN.
                        Email = user_email@stevenjordan.net; add.
         → [General Tab]
                   Friendly name:  user_device@stevenjordan.net
         → Click OK.

         → Request Certificates:  Add checkmark for User Device Auth → Click Enroll.
  • Note that status = Pending.
Step 3:   Approve request from Certificate Authority (CA) server.  

  • Open CA Server  MMC:
       → Certification Authority (Local) → Root-CA →  Pending Requests → Issue: 
Step 4:  Export certificate from workstation that initiated request:  
  • Certificates → Current User →  Certificate Enrollment Requests:
    → Certificate Export Wizard
         → Export Private Key:  Yes, export the key.
         → Export File Format:  Check Include all certificates in path.  Next.
         → Select Policy: No changes.  Click Next.
         → Security:  Check Password.  Enter Password.  Next.
                               N.B., Password = choose_password
         → File to Export:  Choose location:  C:\source\cert\user_device.pfx.  Next.
         → Export Root Certificate and VPN server certificate:  Location: \\securefileshare\
  • Repeat similar process to export CA public root certificate (CER).
  • Log onto the VPN server and repeat similar process to export public certificate (CER).
Step 5:  Distribute certificate files to client devices.
  • Distribute the client certificate and private key (e.g., PFX).  
  • Include the public VPN server and root certificates (e.g., CER).

Distribution methods: 

Security Considerations:

Safeguard your client PFX files!!  PFX files include certificates and their private keys.  An attacker can use this information to impersonate identity.  That means, it can be used to connect to the VPN, collect email, etc.  Do not let these PFX files fall into the wrong hands!  Mitigation:
  • Account for all PFX instances -these are security vulnerabilities!
  • Delete/ remove all device certificates generated from workstations.
  • Save client PFX file to secure off-line media. 
  • Consider IT policy that requires face-to-face installation with IT staff.
  • Email attachments can be forwarded -risk!
  • Internal web server on internal Wi-Fi SSID is preferred.  
  • Ad-Hoc Wi-Fi may be preferable to infrastructure mode. 
  • Do not enable the certificate's export flag.
  • Do not install on any rooted or jailbroken device.  
  • Ensure devices use encryption and passcodes.
  • Above all, use common sense!

That's It!

CA Template for VPNs

Task: 

Prepare Windows CA certificate template for end-user enrollment.

Assumptions:  


  • These instructions are for situations that require minimal VPN support.
  • This solution only supports enrollment requests from the Windows certificate snap-in.
  • It enforces administrative approval for end-device enrollment -this is not a completely automated process.
  • Workplace Join is the preferred method for device enrollment.  It provides self-service automation.  It provides secure key management.  This walk-through is not for Workplace Join.

Steps:


  1. Open certificate templates.  From the Windows CA:  Start → MMC → File → Add Snap-In:  Add Certificate Templates.
  2. Step 2:  Duplicate User template:  Certificate Templates → Right-Click on User (Template) →  Duplicate Template.  
  3. Step 3:  Edit Properties of New Template (Table 1):


Table 1:  New Certificate Template Properties.
Field
General
Cryptography
Extensions
Security
Template Display Name
User Device Auth



Validity Period
3 Years



Publish in AD
Un-check



Minimum key size

2048 or 3072


Providers

Microsoft RSA


Applications Policies


Client Authentication

Authenticated Users



Allow Read
Allow Enroll
Note:  3072 key size increases security strength for IKEv2 VPNs.  Choose validity to fit needs of organization.  Use short validity period for automated self-service (e.g., Workplace Join).  Disable certificate exports for automated self-service.   

The template becomes available for user enrollment requests from any Windows certificate snap-in.

How To Enable Startup PIN for BitLocker


Summary:  How to enable Bit-Locker PIN for pre-authentication prompt.

Problem:  BitLocker encryption protects offline data.  Windows uses an encryption key stored in the TPM.  Therefore, the computer is vulnerable to authentication bypass compromises after Windows starts.  Data only remains fully encrypted (i.e., secure) before the operating system starts.

The BitLocker PIN is an optional security feature.  The computer will not load (i.e., boot into) Windows without PIN authentication.

Solution:  Enable and enforce the Bit-Locker startup PIN.

Instructions:

Use Group Policy Management or Local Group Policy Editor:

Computer Config > Administrative Templates > BitLocker Drive Encryption > Operating System Drives


Policy Settings:

     Allow enhanced PINs for startup:
       --Enabled

     Settings for computers with a TPM:
       --Configure TPM startup:  Allow TPM
       --Configure TPM startup PIN:  Require PIN with TPM
       --Configure TPM startup key:  Allow startup key with TPM
       --Configure TPM startup key and PIN:  Allow startup key and PIN with TPM

N.B., the enhanced PINs provide support for alphabetical and special character use.  This can make the PIN strength stronger and easier to remember.  

Configure Client:

Run the following command with Administrative privileges:
manage-bde -protectors -add c: -TPMAndPIN
That's it!

References:

http://ctogonewild.com/2009/08/28/10-things-you-dont-want-to-know-about-bitlocker/
http://www.pcworld.com/article/3005182/encryption/bitlocker-encryption-can-be-defeated-with-trivial-windows-authentication-bypass.html
https://technet.microsoft.com/en-us/library/jj649837(v=wps.630).aspx
https://technet.microsoft.com/en-us/library/cc766295(v=ws.10).aspx#BKMK_S5




Multi-Factor Authentication Comparison Guide.

Integrate Two-Factor
 Authentication with Windows .
Take Away:  This article examines four multi-factor authentication solutions: (a) RSA SecureID tokens, (b) Microsoft Azure Multi-Factor (MFA) service, (c) certificate-based authentication (CBA), and (d) smartcard authentication.  Each MFA solution integrates with existing Windows' network infrastructure.
  
MFA improves network security by reducing vulnerabilities associated with Windows authentication.  MFA protects against compromise using a token generated one-time password (OTP), or user certificate stored on a smart card, in conjunction with a user account and password.  Malware or hackers cannot use stolen passwords without the additional OTP or certificate.

MFA Introduction: Multi-factor (MFA) or two-form authentication is a system that requires multiple verification methods for user and administrator sign-ins.  MFA requires more than a simple user name and password. The process requires at least two of the following:

Something logical (e.g., password).
Something physical (e.g., smart card).
Something biological (e.g., finger print reader).

Problem:  Compromise of administrator account credentials on domain-joined computers can jeopardize the integrity of the entire domain.  The compromise of remote access accounts can result in the access of sensitive information from external attackers.  Compromise is a consequence from malware, hackers, and additional threats.

Purpose:  The purpose of this MFA research is to:
Safeguard administrator accounts from compromise.
Protect remote access to internal networks.
Secure email on phones and webmail.
Do not compromise usability.

Significance:  MFA provides effective security control in two scenarios: (a) to secure administrator accounts and (b) to secure remote access.   Administrator accounts have a wide range of user rights; and compromise of one of these accounts can provide an intruder access to the entire Windows network.   MFA also provides an additional layer of security for users who require remote connectivity.

MFA enabled networks are less vulnerable to malware and hackers because stolen passwords are only useful with corresponding smart cards (or tokens).  In addition, MFA provides increased security because digital certificates and one-time passwords (OTP) are difficult to forge.

Applicable Use:  In most instances MFA can protect the following systems:

Workstation logins.
Server logins.
Virtual private network (VPN) logins.
Remote desktop services (RDP).
Websites.
Exchange ActiveSync (smart phone email).
Outlook Web Access (OWA).
Radius (e.g., 802.1x, including wireless and wired networks).

RSA SecureID:  RSA SecureID provides two-factor user authentication through the use of hardware (e.g., USB dongle) or software (e.g., smartphone app) tokens.  Token serial numbers are assigned to Active Directory (AD) users on a Radius server.  The tokens generate a random authentication code (i.e., OTP) at fixed intervals (e.g., 60 seconds).  The temporary OTP is unique for each token.  Employees enter the RSA OTP, along with their username and password, during the login process.

Figure 1.  RSA SecureID workflow.
RSA SecureID also strengthens administrator authentication to sensitive servers such as Domain Controllers (DCs), file servers, or databases.  Network administrators should already use dual accounts.  The domain user account is used to log onto workstations for daily tasks.  The domain admin account is used for administrative purposes.  Security is substantially improved when SecureID OTPs are required for all administrative changes.    

The SecureID access manager operates on either RSA appliances or virtual machines (VMs).  The VM servers are included with licensing fees.  At least two access manager servers should run to ensure high availability.  RSA agents are installed on all devices (e.g., workstations, servers, etc…) that require MFA.

Windows Azure MFA:  Windows Azure MFA uses a locally hosted MFA server (VM) in conjunction with an ADFS proxy server for user authentication.  The ADFS Proxy is a service that brokers a connection between external users and the ADFS server.

ADFS is a single sign-on (SSO) technology that can be used to authenticate a user into multiple applications over the course of a SSO.  ADFS allows cross-forest trusts and extends that trust between web applications.  SSO and ADFS ensures user passwords never leave on-premise local servers.  Passwords are never moved to the cloud.

Azure MFA is limited to Web-based and Radius-based authentication.  The service is intended to secure access to remote resources (e.g., RDP, VPN, and Web pages).  The service is not intended to secure administrative roles.

Figure 2.  Microsoft Azure MFA.

CBA Authentication:  Certificate-based (CBA) resources authenticates with user assigned secure socket layer (SSL)/ transport layer security (TLS) certificates.  The user certificate is used in place of entering user credentials.  By itself, CBA is not two-factor authentication. Two-factor authentication is based on something you have plus something you know. CBA is only based on something you have.  However, CBA can be considered MFA when combined with local logins or smart phone pins.

CBA has similar limitations to Azure MFA.  CBA authenticates remote resources (e.g., RDP or Outlook Web App) but it does not secure administrative roles.  Administrators assign user certificates to devices (e.g., laptops).  Private-keys protect assigned certificates and prevent unauthorized copying/exporting.  In the event a device is stolen or lost, the certificate also remains protected with the device login credentials (e.g., Windows), pin number (e.g., phones), and hard drive encryption.  Administrators can easily revoke user certificates when employees report the device as lost or stolen.
 
CBA can also secures Exchange ActiveSync.  Administrators import user certificates to Apple iOS and Windows 8 phones for Exchange authentication.  Exchange policy enforces ActiveSync authentication per user or per group.  Exchange policy also enforces smart phone encryption and can wipe the phone after X number of unsuccessful logins.

CBA requires an enterprise AD CA.  Organizations that do not use domain CAs may want to reconsider this valuable resource.  Windows technology  increasingly depends on SSL certificates.  There is high likelihood that most organizations will require a domain CA in their near future.

Smart Card Authentication:  Smart cards are similar to RSA SecureID tokens.  Smart cards allow robust MFA and can secure administrator access to internal production servers.  Smart card authentication of secondary actions enables better segregation of user and administrator accounts.  Smart cards also provides domain user accounts MFA to workstations, applications, and other local resources.  Smart card drivers and functionality is included with Windows; external agents are not necessary.

Smart cards require an enterprise AD CA infrastructure that can be used with CBA.  Administration is mostly accomplished with CA policies and group policies.  Smart cards use memory to store private keys and user certificates.  The private key cannot be extracted from a smart card.  Smart cards require a password in addition to certificate authentication.  Physical cards and readers are the only hardware expense.

Conclusion:  Each MFA solution introduces similar benefits.  The primary differences are administrative support, end-user devices, and cost.  MFA advantages are summarized (Table 3).  RSA SecureID has a good reputation and may be the easiest solution to implement.  The disadvantage to RSA is that third party agents are required on every server.  RSA is also the most expensive solution available.  Windows Azure MFA is affordable but it only protects remote access servers; it does not provide MFA for administrative accounts.  Smart card and CBA are the most affordable solutions.  Smart card implementation is moderately complicated because it requires AD CA infrastructure.  However, AD CA services will provide most organizations additional benefits in the near future.  Smart cards offer the best value because of their affordability and integration with Windows infrastructure.

MFA technologies are briefly compared (Table 1).

Table 1
MFA Brief Comparison

MFA
Authentication
Requirements
Installation
RSA SecureID
One time password (OTP) generated from end-user tokens (e.g., USB dongles).
RSA SecureID requires (VM) RSA authentication servers.  RSA server agents install on devices and servers.
Modest Installation.

MS Azure
OTP using soft tokens (e.g., smart phone app).
MS Azure MFA requires local Active Directory Federated Services for external authentication (ADFS).
External access via locally hosted web proxy server in DMZ connects to an on-premise MFA Azure server.
Moderate installation.
Certificates
Certificate-based.  Certificates are stored on devices (e.g., laptops).
Certificate based user authentication requires a Microsoft PKI infrastructure (AD Certificate Authority [CA]).
Moderate to complex installation.

Smartcards



Certificate-based.  Certificates are stored on external smart cards. 
Smart cards require AD CA infrastructure.  Smartcards and readers are the only hardware requirements.

Moderate to complex installation.












Pricing for MFA solutions are compared (Table 2).

Table 2
MFA Pricing per Technology
     MFA
Licensing and Equipment
         Fees
RSA SecureID
RSA VM servers included with licenses. 


One time purchase of Authentication Users licenses$81 per user.  Minimum 10 users: 
$810

3 Year Tokens.  $55 per token. 
Minimum 10 users:
$550

Annual Maintenance (SA).
$28 per user.  10 users: 
$280

*Tokens and maintenance are reoccurring expenses.


Total installation for 10 Users:
$1640 (one time).

Total reoccurring (every 3 years) for 10 users:
$1390 (every 3 years).
MS Azure
On-premise server included with Azure licenses.
ADFS and IIS proxy included with current 2012R2 Data Center licenses.


$2 Per user per month subscription. 
10 users per year:

$240 (annually).

Certificates
AD CA server included with 2012R2 Data Center licenses.  No additional out-of-pocket fees.

N/A
Smart Cards
Smart cards are dependent on AD CA infrastructure.


One time $30 per smart card per user.  10 users:
$300

One time $30 per smart card reader per user.  10 users:
$300

Total one-time price for smart cards and readers; based on 10 users:
$600







Table 3. 
MFA Pros and Cons Summary


MFA
Agent
Required
Secure
Remote
Secure
Admin
Easy to
 Replace
Token/ Card
Cost per License
Recurring
Fees
Est.Total
Cost
RSA
Yes
Yes
Yes
Yes
$56
$81
$46/y
High
MS Azure
No
Yes
No
Yes
N/A
N/A
$24/y
Medium
Certificates
No
Yes
No
Yes
N/A
N/A
N/A
Low
Smart Card
No
Yes
Yes
Yes
$60
NA
NA
Low

How to Sign Your PowerShell Scripts

By Steven Jordan on 4/17/2014.

Takeaway:  Sign PowerShell scripts with a code signing certificate.

Assumptions:  We'll assume a code-signing certificate is already installed the Windows certificate root store.  If you don't already have a code-signing certificate, obtain one:
  1. Enroll with the Windows Certificate Authority (CA) server.
  2. Enroll with a public CA.  Best option if you plan to publicly distribute your scripts.
  3. Generate a self-signed certificate.

Use the code-signing certificate located in the the Windows Certificate Store to sign PowerShell scripts.  First, export the certificate from the Certificate Store.  Export the certificate as follows:

Start → MMC → Add/Remove Snap-In → Certificates → Personal → Right click on the certificate → Export.

Save the certificate as a PFX file in a directory of your choice (e.g., c:\scripts).

Lastly, use the following PowerShell script to sign the code:

PS C:\scripts> $cert = Get-PfxCertificate C:\scripts\codesigncert.pfx  C:\scripts> Set-AuthenticodeSignature -Filepath pruneVSS.ps1 -Cert $cert

Directory: C:\scripts SignerCertificate Status Path ----------------- ------ ---- 2603FCAA10343AE1DD78AB41D984728D657499D3 Valid pruneVSS.ps1

That's it -the PowerShell script is signed.  Time to change the set-execution policy throughout the domain!

How to Create a Self Signing Certificate

PKI/ SSL
by Steven Jordan on 4/16/2014

Take Away:  Use Microsoft Windows and its MakeCert tool to create free SSL certificates.  These custom-made certificates can be added as trusted resources for individual users and computers.  Their primary use is generally for testing purposes, code-signing, and other unique situations. 

Create certificates in three easy steps:
  1. Download MakeCert:  Use the Microsoft tool called MakeCert to generate the certificate.  Microsoft includes MakeCert with their Windows 8 Software and Development Toolkit.

    *Hint, choose the Windows App Certificate Kit to avoid downloading the entire SDK.



    MakeCert is also available for download on my OneDrive.
  2. Create a Certificate and Private Key: 

    a.) Makecert.exe is located in the c:\Windows Kits\8.0\bin\x64 directory by default.  Feel free to copy it to a different location.

    b.) Run makecert.exe with the following extended options: 

    C:\scripts>makecert -n "CN=Self Sign Cert" -a sha256 -eku "1.3.6.1.5.5.7.3.3" -r -sv root.pvk root.cer -ss root -sr localmachine

    N.B., -n=Subject Name; -a=digest algorithm; -eku=Enhanced Key Usage, OID; -r=self signed; -sv= Subject PVK file; -ss=Certificate Store Name; -sr=Certificate store location.

    d.)  The above command requests a new private key password. 



    e.)  The new private key and certificate file are located in the same directory as the Makecert application.
  3. Pair the Certificate and Private Key:

    a.) Run the following command:

    C:\scripts>makecert -pe -n "CN=PowerShell local certificate root" -ss MY -a sha1 -eku "1.3.6.1.5.5.7.3.3" -iv root.pvk - ic root.cer

    b.) The above command requests the private key password.



    c.) The certificate pair automatically imports into the Windows Certificate Store.  This is confirmed using the MMC Certificate Snap-In.

    Start → MMC → Add/Remove Snap-In → Certificates → Personal 



That's It!

References:

http://blogs.msdn.com/b/kaushal/archive/2013/06/13/working-with-wild-card-certificates.aspx
http://kreelbits.blogspot.com/2013/09/deploying-signed-powershell-scripts-in.html
http://technet.microsoft.com/en-us/magazine/2008.04.powershell.aspx

Outlook S/MIME Email Encryption


Takeaway:  This article provides an email encryption walk-through.  There comes a time when every organization requires secure email.  Setup email encryption organization-wide or per individual with these simple steps.

PGP:  There are a number of expensive encryption products available but organizations that use Outlook can (and should) use the built-in tools made freely available by Microsoft.  The same technology that protects web sites provides encrypted email -SSL certificates. 

To be fair, there are alternatives to SSL email encryption.  For instance, Pretty Good Privacy (PGP) is an open source encryption protocol.  PGP has a good (pun) reputation with third-party Outlook plugin support.  PGP's greatest flaw is that it is not widely accepted.  Why bother with email encryption that business partners don't support?

I suspect SSL based encryption is popular because of its native Outlook support.  It's worth mentioning that any S/MIME email client supports SSL based encryption (e.g., Firefox and Mac Mail).  In addition, SSL certificates allow for email encryption and also validates a sender's identity.

SSL:   Outlook validates certificate authenticity using a public key infrastructure (PKI).  Trusted root certificate authorities (CAs) issue X.509 (i.e, SSL) certificates to individuals and businesses.  Most web browsers and email clients trust X.509 certificates issued by the handful of public root CAs (e.g., GoDaddy).
Fig. 1.  Individuals and businesses obtain X.509 (i.e., SSL) certificates from root CAs,

Digital Signatures:  SSL certificates consist of a private key and a public key.  The private key is the basis for digital personal identity.  Private keys ensure integrity and confidentiality; and must remain a guarded secret.  Digital signatures use private keys (i.e., digital IDs) to sign outbound email messages.

When Outlook signs a message it first creates a message digest based on mathematical functions (i.e., hashing).  The message digest is a unique and summary of the original data.  Outlook then uses the private key to encrypt the message digest.  The encrypted message digest is the digital signature.

N.B., the message digest is not the same thing as the message. The message digest is encrypted in the digital signature but the message contents remain unencrypted (huh?).  Keep in mind that the private key encrypts the message digest.  The receiving side uses the public key to decrypt the message digest.  Recall, the private key is a well kept secret -only the sender can sign messages with it.  This process establishes the sender's identity and validates the authenticity.  We can be reasonably sure the sender is, who they claim to be, when they include a digital signature.

Content Encryption:  Why does the private key encrypt the message digest but not the message contents?  The answer is because SSL certificates use asynchronous (i.e., one-way) encryption.  Private-keys decrypt public-key encryption, and public-keys decrypt private-key encryption.   It's pointless to encrypt message contents with a private key when everyone has access to the public key.  Why lock a door if everyone has the key to open it?  


Outlook never encrypts message content with a sender's private or public keys.  Outlook therefore, uses the recipient's public key to encrypt messages content.  This process ensures confidentiality because only the recipient can decrypt the message with their super-secret personal key. 



Outlook Encryption Process
  1. Both parties must exchange digitally signed emails before encryption is possible.  The process stores the senders’ digital signature (i.e., public key), in the recipients’ contact list.
  2. New messages are encrypted just before the message is sent.  The new message window contains an Encrypt, and a Sign button in the Options ribbon.   The encrypt option is only available if the recipient’s digital ID (public certificate) is stored in the contact list.


Fig 2.  Outlook Encryption Process Flow


Updated on 4/6/2014 by Steven Jordan.


References:
http://technet.microsoft.com/en-us/library/cc962021.aspx
http://office.microsoft.com/en-us/outlook-help/overview-of-certificates-and-cryptographic-e-mail-messaging-in-outlook-HP001230534.aspx

http://technet.microsoft.com/en-us/library/cc962033.aspx



Import and Assign StartSSL Certificates in Windows, Part 4 of 4.

Setup StartSSL Certificates:  Import and Assign StartSSL Certificates in Windows,  Part 4 of 4.

Last updated  March 2nd, 2014 by Steven Jordan

Takeaway:  This article introduces the Windows Certificate Store.  The Microsoft Management Console (MMC) Certificate Sanp-In imports the StartSSL certificate for use with any SSL application.    This is the forth part in a four-part series on how to use StartSSL certificates.

Additional StartSSL articles: 
1.  Sign-up:  Resister with StartSSL.
2.  Personal Certificates:  Back-up and authenticate to StartSSL with personal certificates.

3.  New Cert:  Generate the StartSSL certificate.
4.  Windows Certificate Management:  Import the StartSSL certificate into Windows.


Install the Certificate:

   There is a common misconception that IIS is responsible for the entire certificate management process.  Of course, you can continue to use the limited IIS certificate tools. 
Managing Certificates via IIS.
  
    However, you'll miss out on some great benefits:  Maintain private keys; deploy single certificates to multiple servers; use certificates for applications other that IIS (e.g., BranchCache, VPNs, Smartcard, etc...); and learn the foundation of Windows PKI.  Drop the IIS certificate tool and welcome the wold of the Windows Certificate Manager.


1.  Open the Certificate Snap-In:

   Import the PFX with the Windows Certificate Snap-In:  Click Start Run → type certsrv.msc.

   The MMC is an alternative method to access the Certificate Snap-In:  Start →  Run → type mmc

   From the MMC:  File → Add/ Remove Snap-In →find and click Certificates → click Add → choose to manage certificates for the Local Computer →click OK.
  
   The Local Computer Certificates Snap-In presents a logical view for all certificates associated with the computer.  Certificates in the Computer store are also accessible from the user certificate store (similar to Group Policy management).

2.  Start the Import Wizard.

   Managed certificates (i.e., those with private keys) are located in the Personal certificate store.  To import a PFX, expand the Personal folder →  right click on Certificates → click All Tasks → click Import.
 The Certificate Import Wizard begins.  From the Wizard, browse to the directory that contains the PFX file.  It's important to change the file type from X.509 Certificate to Personal Information Exchange:

   Click on the PFX file and click Open and click Next.

 3.  Private Key Protection.

   Type or paste the private key password in the appropriate field.  You may mark the key as exportable.  Check Include all extended properties.  Click Next.
 4.  Choose the Certificate Store Location.

Use the default location (i.e., Personal), and click Next and Finish.   

 The StartSSL certificate installation is complete.  The certificate works with any SSL enabled application.  The following example demonstrates how to use the certificate with IIS. 


Assign the StartSSL Certificate to an IIS Site:

1.  Open IIS.

Start → Administrative Tools → Internet Information Service (IIS) Manager.

2.  Edit site bindings.

From the IIS Manager, click the server name → expand the sites folder → select your web site → click on Bindings.
 3.  Assign the StartSSL certificate.

Check for a https binding.  Click on the Add button if there is no https binding.

If the https binding is listed,  highlight the https binding, and click Edit.


4.  Edit Site Bindings:

Type:  
https
IP address
:  Add the site IP or choose all unassigned.
SSL Certificate
:  Choose your new StartSSL certificate.

Click OK. Your StartSSL certificate is now assigned to your website and accepts secure connections.
  


Conclusion:

  StartSSL may not be the perfect fit for every situation.  For example, VeriSign is well known and may provide piece-of-mind to potential customers.  The VeriSign brand is worth the extra few hundred dollars when inferred trust translates to additional sales.

  Windows CA is a better choice for domain joined computer and users.  Windows CA falls short for hosting public facing sites for non-domain computers.  The Windows CA certificates can be imported into private trust stores -but the warnings and additional steps will scare end-users.

  StartSSL is best suited for web development and staging environments.  It's also a good choice for hosting public facing, and non-sales related, resources (e.g., email servers).  I encourage network administrators, developers, and technology enthusiasts to take advantage of this great service.