Oct 302013

Certutil is a really useful tool for administering various parts of a Microsoft CA, but not all the switches are documented – they don’t even show up when you do a ‘certutil -v -?’ to show the full help.

So far, I have found the following verbs and options – the verbs have documentation if you specify them on the command line e.g. ‘certutil -setsmtpinfo -v -?’ I have only included the ‘hidden’ verbs and options below – you can find the standard options by checking the certutil help.

If you have any other verbs and options I’ve missed, please let me know in the comments and I’ll add them to this page. If you have any clever ways of using certutil, please let me know – I’m always looking for better ways of doing things!

Note: Microsoft may have hidden these options for a reason – use them with care, and at your own risk! Microsoft probably won’t provide support if you hit problems!

CertUtil [Options] -setsmtpinfo LogonName
Set SMTP info
[-config Machine\CAName] [-p Password]

CertUtil [Options] -getsmtpinfo
Get SMTP info
[-config Machine\CAName]

CertUtil [Options] -7f CertFile
Check certificate for 0x7f length encodings

CertUtil [Options] -Class [ClassId | ProgId | DllName | *]
Display COM registry information

CertUtil [Options] -CNGConfig
Display CNG Configuration

CertUtil [Options] -csptest [Algorithm]
Test CSPs installed on this machine
[-user] [-silent] [-csp Provider]

CertUtil [Options] -csplist [Algorithm]
List CSPs installed on this machine
[-user] [-silent] [-csp Provider]

CertUtil [Options] -delkey KeyContainerName
Delete named key container
[-user] [-silent] [-csp Provider]

CertUtil [Options] -key [KeyContainerName | -]
List key containers
[-user] [-silent] [-csp Provider]

CertUtil [Options] -SCDump [ReaderName]
Dump smart card file information
[-f] [-silent] [-split] [-p Password]

CertUtil [Options] -URL InFile | URL
Verify Certificate or CRL URLs
[-f] [-split]

CertUtil [Options] -SetCASites [SiteName]
Set Site Names for CAs
[-f] [-silent] [-config Machine\CAName] [-dc DCName]

CertUtil [Options] -SetCATemplates [+ | -]TemplateList
Set templates for CA

CertUtil [Options] -dsAddTemplate TemplateInfFile
Add DS Templates
[-dc DCName]

CertUtil [Options] -dsTemplate [Template]
Display DS Template Attributes
[-silent] [-dc DCName]

CertUtil [Options] -dsDeltaCRL [FullDSDN] | [CRLIndex [OutFile]]
Display DS Delta CRLs
[-enterprise] [-user] [-config Machine\CAName] [-dc DCName]

CertUtil [Options] -dsCRL [FullDSDN] | [CRLIndex [OutFile]]
Display DS CRLs
[-enterprise] [-user] [-config Machine\CAName] [-dc DCName]

CertUtil [Options] -dsCert [FullDSDN] | [CertId [OutFile]]
Display DS Certificates
[-enterprise] [-user] [-config Machine\CAName] [-dc DCName]

CertUtil [Options] -dsDel CN
Delete DS DNs
[-split] [-dc DCName]

CertUtil [Options] -ds [CN]
Display DS DNs
[-f] [-split] [-dc DCName]

CertUtil [Options] -getcert [ObjectId | ERA | KRA [CommonName]]
Select a certificate from a selection UI
[-silent] [-split]

CertUtil [Options] -enumstore [\\MachineName]
Enumerate certificate stores
MachineName — remote machine name.
[-enterprise] [-user] [-GroupPolicy]

CertUtil [Options] -exportPFX [CertificateStoreName] CertId PFXFile [Modifiers]
Export certificate and private key
CertificateStoreName — Certificate store name.  See -store.
CertId — Certificate or CRL match token.  See -store.
PFXFile — exported PFX data output file
Modifiers — Comma separated list of one or more of the following:
NoChain — Do not export the certificate chain
NoRoot — Do not export the root certificate
Defaults to personal machine store.
[-f] [-enterprise] [-user] [-GroupPolicy] [-split] [-p Password] [-t Timeout]

CertUtil [Options] -CAPropInfo
Display CA Property Type Information
[-config Machine\CAName]

CertUtil [Options] -getconfig3
Get configuration via ICertConfig

CertUtil [Options] -getconfig2
Get default configuration string via ICertGetConfig

Options: (I can’t find any info about what these do – some experimentation will be required!)

Sep 232013

What happens if an attacker compromises your root private key?

SSL certificates are used to authenticate clients and servers and to provide a means of securely sharing a secret key which is then used to encrypt communication between the server and client.

In order to do this, you have to have a level of trust in the body which issues the certificates; the Certification Authority or CA.

The way this works in practice is that you place the Root Certificate of the Certification Authority in your ‘Trusted Root Certification Authorities’ store on your computer. This says ‘I trust all certificates signed by the private key associated with this certificate’. Since the private key is only known by the Certification Authority, any certificate signed with the key must have been issued by the authority, and passed all the checks as defined in their CPS (Certification Practice Statement).

Once the infrastructure is in place, the flow is as follows:

SSL flow

Over complicated diagram showing keys and certificates.

  1. The client connects to the web server and requests a secure connection.
  2. The web server sends its certificate which includes a public key.
  3. The client verifies the certificate by checking the name matches the site name, that it has not expired (or been revoked) and that it is signed by a trusted authority.
  4. The client chooses a symmetric encryption key and encrypts it with the public key from the certificate. This is sent to the server
  5. The server decrypts the message with its private key. The browser and web server now share a symmetric key which is unknown to anyone else. This key is used to encrypt all communication for the rest of the session.

The security of the above transaction relies on the private key being stored securely by the web server. If someone had access to that key, they could decrypt the message containing the secret symmetric session key and therefor read all the encrypted messages which follow during that session. However, its unlikely that the owner of the web server would allow the key to leave the server. If an attacker managed to compromise the server to such an extent that he had access to the key, he would have full control of the server and would be able to access the communication anyway. If a government requested the key through legal means, they would be able to read all the communication but, again, they would get much more information by just requesting full access to the server.

So everything is nice and safe as long as the private key is kept secure. (There are, of course, other problems if, for example, there is malware on either end, but I’m ignoring that here).

So, what happens if someone gets access to the Certification Authority’s Private Key either by compromising their key store or by demanding it via legal channels?

Having the root private key would still not allow the attacker to intercept the symmetric key as it is encrypted using the public/private keypair generated by the web server, and the private key is still only known by the web server. It would, however, allow the attacker to create his own certificate and sign it with the Root CA private key. This would mean that it is trusted by the client computer and it would be very difficult to tell it apart from the genuine server certificate.

The attacker can now perform a ‘Man-in-the-middle’ (MITM) attack to capture all the traffic between the client and server. He does this by posing as the web server and authenticating with the client. The client now sends the symmetric key to the attacker encrypted with the attacker’s public key. The attacker decrypts the key and sets up a secure connection with the client. At the same time, the attacker connects to the genuine site and poses as the client. The attacker acts as a proxy between the client and server and can read both sides of the communication. Further, the attacker can change the information from either side. Say, for example, you think you are connected to your bank and you check your balance. The attacker can report the correct balance, but in the background could transfer all your money into his own account. If he needs any extra passwords, or a two-factor authentication, he can prompt you for those details and, if its convincing enough, you may be fooled into providing what he needs.