Signierte Emails Office365: Zertifikat von eigener PKI oder Comodo?

[4zap 17]

Hi

 

für einen 600 User Tenant soll ich signierte Emails bereitstellen. Es gibt eine eigene PKI die ich dafür genommen hätte. Jetzt hat der CTO Bedenken, ich soll ein Comodo Zertifikat nehmen. Halte ich für Blödsinn. 

Wo ist der Unterschied zwischen einem gekauften oder einem selbstausgestellten von der PKI?

 

Find da nicht wirklich was mit Tante Google. Kann mir da jemand ob ich mit dem selbstausgestellten irgendwo Probleme bekommen könnte?

[NilsK 2.785]

Moin,

 

wenn du Mail verschlüsseln willst, braucht der Kommunikationspartner dein Zertifikat und muss diesem vertrauen. Das bedeutet in aller Regel, dass ein kommerzielles Zertifikat besser ist. Sonst hast du jedes Mal das Problem, dass das Root-Zertifikat der eigenen PKI zum Endanwender auf der anderen Seite muss.

 

Gruß, Nils

[4zap 17]

Moin,

 

wenn du Mail verschlüsseln willst, braucht der Kommunikationspartner dein Zertifikat und muss diesem vertrauen. Das bedeutet in aller Regel, dass ein kommerzielles Zertifikat besser ist. Sonst hast du jedes Mal das Problem, dass das Root-Zertifikat der eigenen PKI zum Endanwender auf der anderen Seite muss.

 

Gruß, Nils

Hallo Nils

 

das hab ich befürchtet das ich hier ein kommerzielles nehmen sollte. Dank dir! Das hilft mir iim Vorfeld sehr.

[Squire 211]

ein Zertifikat alleine wird Dir da nichts nützen. Ich denke, dass Du für jeden User ein gesondertes öffentliches SMime Zertifikat brauchst. Bei 600 Usern wird das ein teurer Spaß

[NorbertFe 1.799]

Kommt drauf an, was man als "teuer" bezeichnet. Vor allem sinds wiederkehrende und organisatorische Kosten.

[NilsK 2.785]

Moin,

 

es gibt für sowas auch "Paketlösungen", bei denen man basierend auf einem kommerziellen Zertifikat die Einzelzertifikate selbst erzeugen kann. Ich weiß aber nicht, ob das auch mit Office 365 einsetzbar ist.

 

Edit: Einen Überblick, wie man Office 365 mit einer internen PKI zusammenbringt, gibt es bei Frank Carius:

http://www.msxfaq.de/cloud/exchangeonline/o365smime.htm

 

Er beschreibt auch sehr schön einige der Hindernisse, die sich dabei auftun. Was dort aber fehlt, ist die Frage, wie man das "technische Vertrauen" zur Gegenstelle herstellt - und das ist eben meist mit kommerziellen Zertifikaten leichter herstellbar, weil man nicht neben dem Userzertifikat auch noch das Root-Zertifikat weiterreichen muss.

 

Gruß, Nils

bearbeitet 3. April 2017 von NilsK

[4zap 17]

ein Zertifikat alleine wird Dir da nichts nützen. Ich denke, dass Du für jeden User ein gesondertes öffentliches SMime Zertifikat brauchst. Bei 600 Usern wird das ein teurer Spaß

 

Die Kosten dafür sind nicht gering, ich gehe hier von ca 20 Euro/User für 24 Monate aus.

 

Moin,

 

es gibt für sowas auch "Paketlösungen", bei denen man basierend auf einem kommerziellen Zertifikat die Einzelzertifikate selbst erzeugen kann. Ich weiß aber nicht, ob das auch mit Office 365 einsetzbar ist.

 

Edit: Einen Überblick, wie man Office 365 mit einer internen PKI zusammenbringt, gibt es bei Frank Carius:

http://www.msxfaq.de/cloud/exchangeonline/o365smime.htm

 

Er beschreibt auch sehr schön einige der Hindernisse, die sich dabei auftun. Was dort aber fehlt, ist die Frage, wie man das "technische Vertrauen" zur Gegenstelle herstellt - und das ist eben meist mit kommerziellen Zertifikaten leichter herstellbar, weil man nicht neben dem Userzertifikat auch noch das Root-Zertifikat weiterreichen muss.

 

Gruß, Nils

 

Eigene PKI scheidet aus genau aus diesem Grund: Wie kommt die Gegenstelle an die Root CA?

 

Paketlösung wäre perfekt. Ich installiere das Stammzertifikat von Comodo auf unserer PKI im Azure AD und verteile daraufhin Userzertifkate. Hab ich aber noch nie gemacht, weiß nicht wie ich das anstellen soll. Weiß da jemand mehr oder hat mal ein paar Links zur Hand? Vermute das ist nicht ohne.

[DocData 85]

Das geht so auch nicht. Ihr müsstet eure CA zu einer Sub-CA von Comodo machen. Viel Spaß beim Geld sammeln. Das kannst und willst du nicht bezahlen.

[testperson 1.528]

Hi,

 

Zertificon hat z.B. für sein Mailgateway einen "CA Connector" mit dem sich automatisiert die Zertifikate bei externen Trustcenter ausstellen lassen. Das hieße ja, dass die Trustcenter entsprechende Schnittstellen anböten. Ob dir das aber bei Exchange Online weiterhilft?

 

Gruß

Jan

[NilsK 2.785]

Moin,

 

zumindest gab es mal Paketlösungen, bei denen man über eine Schnittstelle automatisiert Personenzertifikate ausstellen lassen kann. Auf die Schnelle finde ich das nicht wieder, möglicherweise gibt es das auch nicht mehr. Selbst wenn, wäre aber die Frage, ob sich das mit Office 365 integrieren lässt - vermutlich nicht. Das ist eher was für Gateway-Lösungen.

 

Was es aber gibt, sind Zertifikatspakete, mit denen man eine größere Zahl von Personenzertifikaten erwirbt. Die sind dann auch wieder nicht gar so teuer, zumal es dort Staffelrabatte gibt.

 

Gruß, Nils

[4zap 17]

Moin,

 

zumindest gab es mal Paketlösungen, bei denen man über eine Schnittstelle automatisiert Personenzertifikate ausstellen lassen kann. Auf die Schnelle finde ich das nicht wieder, möglicherweise gibt es das auch nicht mehr. Selbst wenn, wäre aber die Frage, ob sich das mit Office 365 integrieren lässt - vermutlich nicht. Das ist eher was für Gateway-Lösungen.

 

Was es aber gibt, sind Zertifikatspakete, mit denen man eine größere Zahl von Personenzertifikaten erwirbt. Die sind dann auch wieder nicht gar so teuer, zumal es dort Staffelrabatte gibt.

 

Gruß, Nils

kurzes Update:

 

Genau so wirds aussehen. GlobalSign bietet ein Rootzertifikat an was genau das kann und auch O365 kompatibel ist. Wenn umgesetzt werd ich mal berichten. Bin sicher nicht der Einzigste der die Frage hat.

[4zap 17]

Huhu

 

kurzes Update damit der Beitrag auch Sinn macht. Die managed PKI's lassen sich die kommerziellen Anbieter richtig gut vergolden. Die Preise für alle MA übertreffen meine bösesten Erwartungen. Somit ist managed PKI gestorben, die laufenden Kosten sind zu krass wenn man bedenkt wir haben einen eigene CA im Azure stehen.

 

Signierte Emails brauchen wir in erster Linie für die Partnerkommunikation. Somit hat ich einfach eine SubCA im Azure aufgesetzt, mit der RootCA verbunden, die CRLs und Zertifikatskette öffentlich ansprechbar gemacht und am Ende Userzertifikate für Emailsignierung, verschlüsselung per autoenrollment verteilt. Hat ein paar Tage gedauert aber jetzt haben alle User ihr Clientzertifikat und der Empfänger kann über die SubCA auf CRL und EntepriseCA erreichen. Klappt. War aber buggy.... es gibt wohl einen Bug wenn man das erste Mal einen request Richtung RootCA schickt.