it:ad:certificates:ssl:creating

IT:AD:Certificates:SSL:Creating

//One might be used to using  IIS7.0's method for creating a self-signed server authentication cert:
:ssldiag /s:1 /selfssl /n:"CN=*.xact-solutions.com" /v:1780
//But one shouldn't for this case...(won't produce a cert that is CA capable, only good for SSL)

//Same for the tool that is built into IIS 7.0...(which I would avoid anyway and use the command line tool anyway)

Note: according to http://skysigal.xact-solutions.com/Blog/tabid/427/entryid/2444/Default.aspx, it's using

 aspnet_regiis -pc "MyKeys" –exp

under the hood.

  • Open a Cmd prompt with Elevated Priveleges
  • Type makecert -! to see the extended version of makecert -?

Using:

  • -n: It's for the domain called “ssldemo….” (-n)
  • -b -e: It's valid between two dates (-b -e)
  • -sky: It's to be used for both signing and encryption (-sky exchange, rather than just sky signature)
  • -r: It's self signing (-r)
  • -pe: It's exportable (-pe)
  • -sv: Save the private key to fakeRootCA.pvk (-sv)
  • Name the new certificate “fakeRootCA.cer” (tip: the output file (fakeRootCA.cer) goes at the end, after all the switches).

One can make a self signed CA:

makecert -n "CN=fakeRootCA" -b 01/01/2007 -e 01/01/2010 
         -sky exchange -r -pe -sv fakeRootCA.pvk fakeRootCA.cer 

The output will be two files:

C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin>dir fakeRootCA*

04/10/2010  09:15 p.m.               501 fakeRootCA.cer
04/10/2010  09:13 p.m.               636 fakeRootCA.pvk 

Once build, install the CA cert to the Trusted Root store, using either the wizard or the command line:

certutil.exe -f -addstore Root fakeRootCA.cer

Note that you can combine both steps (create CA + install it to Trusted Root) in one step:

makecert -n "CN=fakeRootCA" -b "10/01/2010" -e "10/15/2010" -sky exchange 
         -sv fakeRootCA.pvk -sr LocalMachine -ss Root -r -pe fakeRootCA.cer 

Note: Regarding where to put it:

AddressBook: store for use by other users
AuthRoot: store containing 3rd party certificate authorities (CAs)
CertificateAuthority: store for intermediate authorities
Disallowed: store for revoked certificates
My: store for personal certificates
Root: store for trusted root CAs certificates
TrustedPeople: store for directly trusted people and resources
TrustedPublisher: store for directly trusted publishers

Now Create the SSL Cert that relies on the CA

MakeCert's relevant keys:

  • -sk: Subject's key container name – to be created if it does not exist.
  • -sv: Subject's key file
  • -iv: The Issuers Private Key File (the .pvk file generated when you generated the CA's certificate above). -n: Certificate subject X500 name (e.g.: CN=ssldemo.xact-solutions.com)
  • -ic: Issuer's certificate file.
  • -sr: Subject's Certificate Store [LocalMachine|CurrentUser] Default is CurrentUser
  • -ss:Subject's certificate store name that stores the output certificate
  • -sky: subject key type [signature|exchange|integer]
  • -pe: mark certificate as exportable

Back to Command Prompt and issue command

makecert -n "CN=192.168.0.10" -sky exchange -b "10/01/2010" -e "10/15/2010" 
         -ic FakeRootCA.cer -iv FakeRootCA.pvk -eku 1.3.6.1.5.5.7.3.1 
         -pe -sr LocalMachine -ss Root -sv demossl.pvk demossl.cer

Make a Cert:

  • -n: Specifically for 192.168.0.10
  • -sky: Make the key good for signatures as well as encryption
  • -b -e: Make it valid for only a limited time
  • -iv: Tie it back to an issuer (in this case fakeRootCA.cer)
  • As we are pretending to be the CA, we have to know it's password – hence the reference to FakeRoot.pvk
  • -pe: We want the certificate to be exportable.
  • -sr: If all goes well, we want it installed on the LocalMachine, in the Personal folder
  • -eku: This cert is for a server, hence 1.3.6.1.5.5.7.3.1
    • Options worth knowing about, btw, are:
      • 1.3.6.1.5.5.7.3.1 - idkpserverAuth
      • 1.3.6.1.5.5.7.3.2 - idkpclientAuth
      • 1.3.6.1.5.5.7.3.3 - idkpcodeSigning
      • 1.3.6.1.5.5.7.3.4 - idkpemailProtection
      • 1.3.6.1.5.5.7.3.5 - id-kp-ipsecEndSystem
      • 1.3.6.1.5.5.7.3.6 - id-kp-ipsecTunnel
      • 1.3.6.1.5.5.7.3.7 - id-kp-ipsecUser
      • 1.3.6.1.5.5.7.3.8 - idkptimeStamping
      • 1.3.6.1.5.5.7.3.9 – OCSPSigning
      • 1.3.6.1.4.1.311.10.3.4 - Encrypting File System
      • 1.3.6.1.4.1.311.20.2.2 - Smart Card Logon
      • 1.3.6.1.5.5.7.3.2- Client Authentication
        • 1.3.6.1.5.5.8.2.2 - IP security IKE intermediate

        * -sv: Save the password to demossl.pvk

  • And we want the output file (the local copy) to be demossl.cer

Run it, first enter the new password you want for the server (not CA/Issuer) then when requested, enter the original password used when you created the CA/Issuer.

Also note that I could use -ic because I have local copies of the CA files…if there were no local files, and I was working off of elements already in the Cert Stores, I would be using the -is / -ir /- is switches:

makecert.exe -n “CN=192.168.0.10” -sky exchange -b “10/01/2010” -e 10/15/2010

  1. ir LocalMachine -is Root -in “My Root CA” eku 1.3.6.1.5.5.7.3.1
  2. pe -sr LocalMachine -ss Root -sv demossl.pvk demossl.cer

Exporting the created Cert to the server

You can then export it to a pfx file by supplying a password.

You then need to combine the pvk and cer together for the server to be able to use the Private Key.

pvk2pfx -pvk demossl.pvk -spc demossl.cer -pfx demossl.pfx

You will be asked for a password – it will be PASSWORD2 (that of demossl.pfx)

At this point you go over to the server, import the *.pfx into the LocalMachine's personal store,

Ensure that the website's bindings allow SSL and tie it back to the cert within the pvk that you just installed.

For the local station's AppPool Identities to have rights to the private key, the imported cert has to be copied from Root to My cert store, then right click, give rights to account – eg: IIS Svc.AP account.

You may be wondering why we imported a pvk, and not cert… Our website Bob has to communicate with Alice – so it not only needs to have the public decryption key within the crt, but also the encryption key within *.pvk

By packaging the whole thing up as a pvk, we easily installed into the server both parts…the pvk being installed to another location.

#### Final Test ####

Final Test…

At this point, both Client and Server both have a fakeRootCA in their Root directory.

The server has a crt specific to its url in its My Store. It also has the pvk safely unpacked somewhere else.

So go back to the first computer (Alice), and direct yourself to the website you are trying to get to…and voila…notice the green.. you did it. Congrats.

  • /home/skysigal/public_html/data/pages/it/ad/certificates/ssl/creating.txt
  • Last modified: 2023/11/04 22:54
  • by 127.0.0.1