VSTO-Setup bauen inkl. digitalem Zertifikat. Das perfekte Zusammenspiel zwischen Cloud und dem lokalen Build-Server

Machen wir uns nichts vor, das Thema kapiert doch kaum jemand. Oder? Du vielleicht? Worum es überhaupt geht? Ganz einfach: Add-Ins für bspw. Microsoft Outlook bedingen, dass sie digital signiert sind. Das hat etwas mit Sicherheit zu tun, oder würdest Du etwa einem beliebigen Add-In aus dem Internet volle Zugriffsrechte auf Deine geschäftlichen Emails, Kontakte u.ä. gewähren? Nein, natürlich nicht! Es sei denn, die Quelle ist vertrauenswürdig. Und da da natürlich jeder kommen könnte, hat sich Microsoft gedacht, es wäre evtl. sinnvoll, dass derartige Add-Ins digital signiert werden. In wenigen Worten bedeutet das nichts weiter, als dass der Hersteller sein Add-In mit einem digitalen Zertifikat unterschreibt und selbiges von einem vertrauenswürdigen Herausgeber gegengezeichnet wurde. So kannst Du als Endkunde nachvollziehen, ob der Hersteller des Add-Ins wirklich der ist, der er behauptet zu sein.

Soweit so gut. Nun ist die Sache die: Vielleicht entwickelst Du gerade ein Add-In und wunderst Dich, warum Dir das Problem noch nie wirklich begegnet ist. Tja, das liegt vereinfacht gesagt daran, dass das Visual Studio durch die Nutzung entsprechender VSTO (Visual Studio Tools for Office) Templates Testzertifikate für die Entwicklung ausstellt und damit Dein Add-In signiert.

Also nochmal:

Outlook zum Beispiel prüft nur das Vorhandensein eines Zertifikates. Ob das auch was taugt, das muss der Anwender bestimmen. Das ist wie mit der dermatologisch getesteten Hautcreme… mal ehrlich: Hast Du jemals gesehen, dass das Ergebnis des “Tests” auf dem Produkt abgedruckt ist? Eben. Selbst prüfen lautet die Devise.

Zurück zum Add-In. Dein Chef hat eine neue Policy erlassen, nach der die Entwicklung in Zukunft nicht mehr gegen einen on premise gehosteten Team Foundation Server, sondern über die Cloud erfolgt. Sprich: VSTS. Darin könne man sogar die Builds automatisieren, behauptet er. Und er hat natürlich Recht. Das funktioniert sogar verblüffend gut! Also lässt Du durch den Produktverantwortlichen in eurem Haus ein Teamprojekt anlegen, lädst Deine Sourcen hoch, konfigurierst einen Build und freust Dich auf den Feierabend.

Moment. Da war doch noch was… ja richtig: Das Zertifikat, das in Form einer Datei beiliegt, ist ja nur ein Testzertifikat. Für die Entwicklung und Testzwecke, sowie Debug-Builds ist das ja noch in Ordnung. Aber was machst Du, sobald das Add-In produktionstauglich ist? Und JETZT wird es spannend!

Ein paar schnelle Fakten

  1. Du kannst sowohl DLLs, wie auch .exe (oder im Fall von Office-Add-Ins) .vsto Dateien, Manifeste wie auch MSI-Setups digital signieren (und solltest es auch tun).
  2. Dafür benötigst Du ein Code Signing Certificate (bei Microsoft nennt sich das Verfahren Authenticode).
  3. Im Prinzip ist es egal, von welchem Herausgeber Du Dein digitales Zertifikat gegenzeichnen lässt, solange er vertrauenswürdig ist (Tipp: StartCom gehört leider nicht mehr dazu).
  4. Zertifikate bestehen aus dem Zertifikat selbst und einem privaten sowie öffentlichen Schlüssel (Stichwort: Public Key Infrastructure).
  5. Du willst NIEMALS NIE, dass jemand an Deinen privaten Schlüssel herankommt! Als Unternehmen ganz besonders nicht!

Und jetzt hast Du ein Problem. Denn mit dem privaten Schlüssen signierst Du Deine Assemblies und mehr. Damit das während des Build-Vorgangs (für z.B. ein Produktionsbuild) funktioniert, könntest Du jetzt Dein Zertifikat inkl. Schlüssel mit in das Teamprojekt einbinden und dann den Buildprozess so anpassen, dass der Output automatisch signiert wird. HALT!

Digitale Signaturen und die Cloud

Noch mal zurück: Die Sourcen liegen im Teamprojekt. Dein Team hat darauf Zugriff. An den Schlüssel sollen sie aber nicht herankommen. Also importierst Du das Zertifikat in Deinen lokalen Zertifikatspeicher und markierst den Schlüssel als nicht-exportierbar. Nun kannst Du den Buildprozess so anpassen, dass der Schlüssel aus dem Zertifikatsspeicher gezogen wird und niemand kann ihn exportieren oder sonst irgendwie missbrauchen – falls Du ihn zusätzlich mit einem Passwort abgesichert hast. Hast Du das nicht,  weil das für den Build “praktischer” ist, ist das zwar in Ordnung, aber nur solange, wie Du sicherstellen kannst, dass niemand sonst Zugriff auf Deine Build-Maschine hat. Hast Du es doch… nun, dann hast Du nun eine neue Herausforderung.

Die hast Du aber sowieso, denn das Build-System in der Cloud kannst Du nun ebenfalls vergessen. Es taugt nur noch für Debug- Test- und Entwicklungsbuilds. Denn da Du grundsätzlich erst einmal keinen Zugriff auf lokale Zertifikatsspeicher auf geteilten Build-Servern in der VSTS Infrastruktur hast, endet der Weg hier für Dich.

Zum Glück gibt es aber die Möglichkeit, einen Remote Build Agent selbst zu hosten. Und zwar z.B. auf Deiner Build-Maschine. Sobald Du einen solchen eingerichtet hast, kannst Du ihn entweder manuell starten (testweise), oder als Dienst im Hintergrund laufen lassen. Er verbindet sich mit dem Teamprojekt in der Cloud und übernimmt den Build, sobald er angefordert wird. Sinnvoll ist es, dazu verschiedene Build-Konfigurationen im Visual Studio Projekt anzulegen. Z. B. eine für Debug-Builds (mit Testzertifikat und ohne Setup) und eine für Test-Builds (mit Testzertifikat und mit Setup), sowie eine für Produktions-Builds (inkl. signiertem Zertifikat und Setup). Sobald Du letztere auswählst, gibst Du Deinen lokalen Build-Agenten als Target an und dieser übernimmt dann alles weitere.

Das alles klingt zu kompliziert für Dich? Sorry, aber das ist nun mal Dein Job. Sicherheit ist essentiell und während das Thema PKI und Softwareentwicklung zwar – das muss ich zugeben – nicht so leicht zu durchblicken ist, bleibt Dir nichts anderes übrig, als Dich sinnvoll damit zu beschäftigen, falls Du Dich mit der Entwicklung von Office Add-Ins beschäftigst. Übrigens wirst Du mit einem netten Gimmick belohnt: Das Betriebssystem gibt Dir grünes Licht bei der Installation. Na wenn das nichts ist!

image_6_1F75650B

Unterstützung für Dein Projekt

Abschließend noch der obligatorische Hinweis: Sollten Dir Begriffe wie PKI, Codesigning, Authenticode, Timestamping & Co wenig geläufig sein, Du stehst aber vor der Herausforderung, diese Techniken in Deinem Projekt einsetzen zu müssen, dann nutz doch einfach die Gelegenheit und sprich uns darauf an! Hier gibt es unser Kontaktformular. Wähle als Betreff einfach “stabile Geschäftsanwendungen” aus und erwähne in der Nachricht, dass Du mit Christian sprechen möchtest.

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading

Über die Autoren

Christian Jacob ist Leiter des Geschäftsbereiches Softwarearchitektur und -entwicklung und zieht als Trainer im Kontext der .NET Entwicklung sowie ALM-Themen Projekte auf links.

Marcus Jacob fokussiert sich auf die Entwicklung von Office-Addins sowie Windows Phone Apps und gilt bei uns als der Bezwinger von Windows Installer Xml.

Martin Kratsch engagiert sich für das Thema Projektmanagement mit dem Team Foundation Server und bringt mit seinen Java- und iOS-Kenntnissen Farbe in unser ansonsten von .NET geprägtes Team.

Aktuelle Kommentare

Comment RSS