Offline Root CA (ORCA)

Diese Anleitung dient der Erstellung einer offline Root CA, kurz ORCA, und besteht aus folgenden Schritten:

  • Vorbereiten der Datei “CAPolicy.inf” für die eigenständige Zertifizierungsstelle
  • Installieren & Konfigurieren der eigenständigen Stammzertifizierungsstelle
  • Konfiguraiton der Website mit dem Public Key Zertifikat
  • Verteilen der Stammzertifizierungsstelle über die Domäne

Vorbereitung

CAPolicy.inf

Die CAPolicy.inf Datei wird unter C:\Windows\CAPolicy.inf abgelegt und dient den Setup Prozess als Vorgabe für Einstellungen (Policy).

[Version]
Signature="$Windows NT$"

[PolicyStatementExtension]
Policies=InternalPolicy

[InternalPolicy]
OID= 1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=http://www.contoso.com/pki/cps.txt

[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
CRLPeriod=weeks
CRLPeriodUnits=26
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=0
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1

Durch Verwenden der Einstellung “CRLDeltaPeriodUnits=0” in der Datei “CAPolicy.inf” wird die Veröffentlichung von Deltazertifikatsperrlisten deaktiviert. Dies ist die korrekte Einstellung für eine Offline-Stammzertifizierungsstelle.

Folgendes muss also im Textfile editiert werden:

  • OID
  • Notice
  • URL

OID

Die im Beispiel der CAPolicy.inf angezeigte Objektkennung (OID, Object-ID) ist die Microsoft-OID. Einzelne Organisationen sollten eigene OIDs anfordern. Der Sinn einer OID ist eine Weltweit einheitliche ID zu vergeben. Dies wird z.B. auch für die ID vergabe von grossen Dokumenten verwenden. Ein bekanner Verwendungszweck ist auch SNMP. Die OID soll auch für interne CA’s angefordert werden:

http://security.stackexchange.com/questions/26516/what-oid-issuance-policies-are-appropriate-for-smartcard-and-browser-certificate

Kostenlose Registration: http://pen.iana.org/pen/PenApplication.page

Abfrage: http://www.oid-info.com/

Notice/URL: Zertifikatverwendungserklärung

Aus “Certificate Practice Statement (CPS)” genannt; Das CPS ist ein Statement darüber, wie die CA Zertifikate ausstellt. Eine genauere Beschreibung befindet sich in RFC2527 in Kapitel “3.5 CERTIFICATION PRACTICE STATEMENT” @ http://www.ietf.org/rfc/rfc2527.txt.

A CPS must contain detailed information on:

  • The procedures used to issue certificates, including the procedures followed to verify the relationship between an entity and its public key. In the case of RPKI, this refers to how the authority to use certain IP address resource is verified.
  • The detailed life cycle of the certificates that are issued, i.e. how to request a certificate, how the certificate is issued, its expiration date, how it is renewed, as well as how and why it may be cancelled.
  • Technical aspects such as a detailed description of the facilities, physical access controls, operational roles, separation of responsibilities, and the auditing controls to be implemented.
  • Technical aspects relating to the generation of cryptographic material and private key management.

Beispiel von Verisign: http://www.verisign.com/repository/CPS/VeriSignCPSv3.3.pdf

Installation der CA

Feature Install & Configure

Die zwei folgenden Befehle erledigen all diese Schritte in einem:

  • Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
  • Install-AdcsCertificationAuthority –CAType StandaloneRootCA –CACommonName “Contoso Root CA” –KeyLength 4096 –HashAlgorithm SHA256 –CryptoProviderName “RSA#Microsoft Software Key Storage Provider”

Anleitung über’s GUI

  • Über den Server Manager die Role “Active Directory Certificate Services” auswählen
  • Bei den folgenden Role Services nur die “Certification Authority” selektieren
  • Nach der Installation nicht schliessend sondern “Configure …” im Text anklicken
  • Es erscheint ein Begrüssungsbildschirm; Admin Acocunt angeben, ORCA1\Administrator oder z.B. ORCA1\CAAdmin wenn der Account umbenannt wurde
  • Role Service “Certification Authority” selektieren
  • Standalone CA, Root CA, New private key
  • Cryptographic options:
    • RSA#Microsoft Software Key Storage Provider
    • Key Length: 4096
    • Hash algorithm: SHA256

-> Abwärtskompatibilität für XP ist nicht nötig bei der Root CA, dafür bei der Subordinate CA

  • Name of the CA
    • Common name for this CA: “Contoso Root CA”
  • Validity Period
    • 20 Years

Konfiguration bestätigen und Konfigurieren lassen.

CA Setup

  1. cervsrv.msc starten
  2. Rechtsklick auf “Revoked Certificates” -> Properties, “Publish Delta CRLs” muss deaktiviert sein
  3. Folgende Befehle ausführen um die Standard Pfade für CFD und AIA festzulegen.

–> Gültigkeit für Auszustellende Zertifikate auf (z.B.) fünf Jahre erhöhen

  • certutil -setreg ca\ValidityPeriodUnits 5

Empfehlung für die Gültigkeit: die Untergeordnete CA ist immer halb so lange gültig wie die Übergeordnete.
Regel für Gültigkeit: die Untergeordnete CA oder Zertifikate dürfen nicht länger gültig sein als die CA.

Publish Certificate URL

Danach muss das CRT File aus dem Pfad C:\Windows\system32\CertSrv\CertEnroll auf dem Webserver mit der angegebenen URL publiziert werden. Diese URL wird in jedem erstellten Zertifikat hartkodiert gespeichert und kann nicht mehr nachträglich angepasst werden.

Security Settings

Folgende NTFS Berechtigungen sind auf dem Ordner nötig.

orca1

Request Filtering

CRL’s von Subordinate CA’s verwenden “+” Zeichen im Dateinamen, weshalb das “double escaping” im Request Filtering aktiviert werden muss. (KB942076)

orca2

CA in Domain vertrauen

Der Trust kann über zwei Wege hergestellt werden: Group Policy oder AD Zertifikatespeicher. Microsoft nimmt in der Anleitung den AD Zertifikatespeicher.

AD Zertifikatespeicher

Das Zertifikat wird im Configuration Store des AD über folgenden Befehl hinzugefügt.

  • certutil –dspublish –f orca1_ContosoRootCA.crt RootCA

Das Zertifikat ist anschliessend an folgendem Ort gespeichert:

orca3

Group Policy

Alternativ kann das Zertifikat über die Group Policy an alle Clients verteilt werden, das Ergebnis sähe dann so aus:

orca4

Fertig.

Advertisements

VMDirectPath owns the local SCSI Controller

Yesterday I was witness of an exciting feature of VMware’s VMDirectPath Feature on ESXi. For those who don’t know: DirectPath allows you to directly attach PCI Devices to a VM.

In our case we installed a secondary SCSI Adapter to attach a tape drive to a VM. In ESX Host that is configured by using VMDirectPath. Unfortunately, fast hands have choosen the wrong adapter. In this case, where you only have two adapters, it’s the SCSI adapter of the disks where ESX ist installed on 😛 it isn’t possible to write down any configuration changes to disk now, because esx has no longer access to the SCSI Controller.

ESX boots up normally. After OS is up, the SCSI Adapter is passed trough to the DirectPath module. From this time on, you see error messages in the logs (ALT+F12 on console).

So, how to get back?

  • Boot another Linux Live CD and change the configuration? Didn’t work in our case, why ever.
  • Reinstall ESX: no.
  • Change the configuration during ESX operation. But how if filesystem is read only?

Here’s my How-To

Run the following on ESX Console (dcui) to get a list of who owns which hba:

pic1

Now let’s assign vmhba1 back to vmkernel:

pic2

Now kernel owns the hba, but before changes can be written to disk, a rescan is required.

pic3

Now let’s modify the esx.conf to permanentely assign vmhba1 to vmkernel.

pic4

To search a String, use “/” in vi; just type “/vmhba1” and hit enter, vi will show up the right line where you can see vmhba1 is assigned to passtrough instead of vmkernel. Some other vi hints for editing:

  • delete text using the DEL key
  • before typing, enter insert mode by pressing key “i”
  • after typing exit insert mode using ESC key
  • to save and exit: “:wq” and ENTER

Now do a reboot to test the new setting. After all now we’re able to assign the next/right hba to the passtrough 😉

pic5