Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)

Vor längerer Zeit habe ich den Exchange Certificate Assistant zum letzten Mal aktualisiert. Das Script verwendet POSH-ACME als Client um Let’s Encrypt Zertifikate automatisch anzufordern, jedoch kommt es mit dem Script immer mal wieder zu Problemen. Da es mittlerweile aber eine deutliche bessere Variante, welche ebenfalls Unterstützung für Exchange Server (und weitere Services) gibt, werde ich den Exchange Certificate Assistant nicht mehr weiter entwickeln.

An dieser Stelle folgt daher ein kleiner Artikel um mittels WIN-ACME Client ein Zertifikat für Exchange Server via Let’s Encrypt anzufordern.

Der WIN-ACME bietet direkt eine Integration für Exchange Server an. Voraussetzung ist die PowerShell in Version 5. Der WIN-ACME Client kann hier runtergeladen werden:

Das ZIP-Archiv kann dann in einen beliebigen Ordner entpackt werden:

Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)

Alles was nun noch benötigt wird, sind die Namen, welche auf dem Zertifikat eingetragen werden sollen. Um die DNS-Namen für das Zertifikat zu ermitteln, kann das Script aus einem meiner vorigen Beiträge verwendet werden:

Danach kann der WIN-ACME Client mit entsprechenden Parametern gestartet werden. Um das Zertifikat für Exchange Server zu konfigurieren, kann der folgende Befehl mit den entsprechenden DNS-Namen angepasst werden:

1
wacs.exe --target manual --host outlook.frankysweb-lab.de,autodiscover.frankysweb-lab.de --certificatestore My --acl-fullcontrol "network service,administrators" --installation iis,script --installationsiteid 1 --script "./Scripts/ImportExchange.ps1" --scriptparameters "'{CertThumbprint}' 'IIS,SMTP,IMAP,POP' 1 '{CacheFile}' '{CachePassword}' '{CertFriendlyName}'"

Am einfachsten ist es, wenn der Befehl in eine CMD-Datei kopiert wird und dann dort angepasst wird:

Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)

Das waren schon alle nötigen Anpassungen, die CMD-Datei kann nun direkt ausgeführt werden. Alternativ lässt sich natürlich auch der Befehl aus der CMD Datei direkt in der Kommandozeile ausführen. Beim ersten Ausführen des WIN-ACME Clients müssen zwei Fragen bestätigt und eine E-Mail-Adresse angegeben werden:

Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)

Nachdem die Ausführung von WIN-ACME abgeschlossen ist, wurde das neue Zertifikat den Exchange Diensten zugewiesen:

Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)

Ebenfalls gibt es einen Task, welcher das Zertifikat automatisch erneuert.

Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)

Es ist also Zeit den Exchange Certificate Assistant in Rente zu schicken und auf den WIN-ACME Client umzustellen. Vielen Dank an das Team hinter dem WIN-ACME Client für die hervorragende Arbeit.

Der Exchange Certificate Assistant war zumindest eines der ersten Scripte, welche Zertifikate für Exchange Server anfordern und automatisch zuweisen konnten. :-)

Vor kurzen habe ich außerdem ein ausführliches Whitepaper zum Thema “Exchange Server und Zertifikate” veröffentlicht, wer sich bei dem Thema Zertifikate noch unsicher fühlt, findet in dem Whitepaper einen ganz guten Einstieg.

37 Gedanken zu „Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)“

  1. Hallo zusammen,
    man liest ja immer mehr das diese Anleitung wohl nicht mehr funktioniert.
    Das Mapping ans SMTP-Protokoll funktioniert bei mir auch nicht, auch kommen viele Fehlermeldungen und die ImportExchange.ps1 Datei will er mir auch nur mit dem Notepad öffnen.

    Vielleicht kann hier jemand unterstützen? Oder man aktualisiert mal diese Anleitung?

    Antworten
  2. Ich hänge auch gerade an dem Thema Zertifikate und Exchange.

    Ich habe deine Anleitung zum Aufbau einer kleinen Exchange 2016 Umgebung befolgt. Dort beschreibst du ja den Weg über Startcom. Diese bieten ja leider keine Zertifikate mehr an. Deshalb der Weg über Letsencrypt.

    Bei mir funktioniert dies allerdings nicht so richtig, da ich Timeouts und DNS-Fehler bekomme.

    Wenn ich das richtig verstanden habe, muss der Exchange von außen über das Internet erreichbar sein, damit WinACME die Zertifikate bei Letsencrypt anfordern kann, richtig?

    Freue mich über Tipps.

    Antworten
  3. Hallo, habe hier gestern schon einen Kommentar geschrieben – habe das gleiche Problem wie Ingo (das Mapping ans SMTP-Protokoll funktioniert nicht). Die Anpassungen von kirstein aus dem neuesten Kommentar habe ich auch schon ausgetestet.

    Mein gestriger Kommentar ist allerdings im Spam gelandet, da ich ihn über eine IP versendet habe, die von Askimet wohl als Spam geblacklistet ist.

    Bitte um Freigabe meines Kommentars, falls möglich. Bin so oder so für jeden Tipp in dieser Sache dankbar. Sofern ich was herausgefunden habe, gebe ich hier auch Bescheid.

    Antworten
    • Tatsächlich ging es mir gestern auch so.
      Das Zertifikat wurde einfach nicht dem SMTP Dienst zugewiesen.
      Zumindest wurde es nicht angezeigt. Fehlermeldungen gab es keine.

      Geholfen hat bei mir die Kommentare und Tips auf dieser Seite zu lesen.
      Zwei Hinweise
      – deutsche Installation Rechte „–acl-fullcontrol „Netzwerkdienst,Administratoren“
      – In der settings.json lässt sich dazu die Einstellung “PrivateKeyExportable” auf “True” setzen:
      in Kombination mit
      – Zertifikat mit den Änderungen neu Ausstellen
      – Zertifikat in eine Datei exportieren
      – Zertifikat in der ecp Konsole erst von Diensten befreien bzw. auf das selbsignierte Zertifikat legen, dann löschen.
      – neu importieren mit Import-ExchangeCertificate
      – mit Enable-ExchangeCertificate den Diensten zuweisen,
      hat es zum Laufen gebracht.

      Ich habe das Gefühl das es auch einfacher gehen würde aber so ließ sich die verknotete Situation wieder retten.
      Danke für diese Webseite
      Jochen

      Antworten
  4. Hallo allerseits,
    bei dem oben aufgeführten Befehl für die Installation des Zertifikates ist mit aktuellen Version (v2.2.4.1500) von win-acme eine Anpassungen erforderlich:

    „./Scripts/ImportExchange.ps1“ muss in „./Scripts/ImportExchange.v2.ps1“ geändert werden.

    Außerdem sei noch darauf hingewiesen, dass bei einer deutschen Installation die Rechte nur mit ‚–acl-fullcontrol „Netzwerkdienst,Administratoren“‚ richtig gesetzt werden.

    Antworten
  5. D:\Zertifikate\win-acme>“network service,administrators“
    Der Befehl „“network service,administrators““ ist entweder falsch geschrieben oder
    konnte nicht gefunden werden.

    D:\Zertifikate\win-acme>–installation iis,script –installationsiteid 1 –script
    Der Befehl „–installation“ ist entweder falsch geschrieben oder
    konnte nicht gefunden werden.

    D:\Zertifikate\win-acme>“./Scripts/ImportExchange.ps1″

    Tut mir leid, aber ich benutze weiterhin die bisherigen Skripte dafür, aber danke.

    Antworten
  6. Hallo,
    ich habe einen Exchange 2019 mit aktuellsten Patch. Wenn ich das noch aktuelle Zertifikat mit WinACME ersteze, dann ist der OWA und der ECP nicht mehr erreichbar.
    hat jemand eine Idee?
    Grüße Rainer Schenkel

    Antworten
    • Beim EPC bekomme ich folgendes:
      Serverfehler in der Anwendung /ecp.
      https://localhost/owa/auth/errorFE.aspx?CafeError=SSLCertificateProblem
      Beschreibung: Unbehandelte Ausnahme beim Ausführen der aktuellen Webanforderung. Überprüfen Sie die Stapelüberwachung, um weitere Informationen über diesen Fehler anzuzeigen und festzustellen, wo der Fehler im Code verursacht wurde.

      Ausnahmedetails: System.Web.HttpException: https://localhost/owa/auth/errorFE.aspx?CafeError=SSLCertificateProblem

      Quellfehler:

      Beim Ausführen der aktuellen Webanforderung wurde einen unbehandelte Ausnahme generiert. Informationen über den Ursprung und die Position der Ausnahme können mit der Ausnahmestapelüberwachung angezeigt werden.

      Stapelüberwachung:

      [HttpException (0x80004005): https://localhost/owa/auth/errorFE.aspx?CafeError=SSLCertificateProblem%5D
      Microsoft.Exchange.HttpProxy.FbaModule.OnBeginRequestInternal(HttpApplication httpApplication) +441
      Microsoft.Exchange.HttpProxy.c__DisplayClass20_0.b__0() +1679
      Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate) +35
      System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +142
      System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) +75
      System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +93

      Versionsinformationen: Microsoft .NET Framework-Version:4.0.30319; ASP.NET-Version:4.8.4494.0

      Antworten
  7. Kurze Info, scheinbar hat sich mit einem der letzten Exchange 2016/2019 CUs etwas an dem Powershell Script geändert. Das Cmdlet Import-ExchangeCertificate akzeptiert kein File mehr. Dafür muss „-FileData“ mitgeliefert werden. Siehe Text zum Example2 unter https://docs.microsoft.com/de-de/powershell/module/exchange/import-exchangecertificate?view=exchange-ps

    Zeile 636 sollte neu zum Beispiel so aussehen:
    Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes($CertPath)) -FriendlyName $SANAlias -Password $ImportPassword -PrivateKeyExportable:$true | Enable-ExchangeCertificate -Services „SMTP, IMAP, POP, IIS“ –force

    Antworten
  8. Hallo,
    ich muss mich leider wieder um uns Zertifikat kümmern, da mit ein das letzte ioS Update keinen Gefallen getan hat. Ich bin nach der tollen Anleitung los marschiert.
    Aber leider ist nach erste drei Punkten schluss.

    Der erste Unterschied ist das bei mir „Cached order has status invaild discarding, “ kommt und nicht vaild.

    Ich hatte vorher ein eignes Zertifikat erstellt, auch nach einer sehr guten Anleitung von Franky. Leider will dieses Zertifikat nicht mehr mit neusten Update von Apple funtkionieren.

    Das script läuft dann weiter und endet auch bei dem Fehler 400. Obwohl alles frei ist.

    Ich hoffe einer kann mit den entscheidenen Tipp geben.

    Vielen Dank

    Muss ich vorher ein Zertifikat bei Let’s Encrypt erstellt haben?

    Antworten
  9. Danke für die gute Anleitung. Funktioniert prächtig, nur die Aufgabe hat sich bei mir nicht erstellt.
    Hat jemand die Möglichkeit, die Eigenschaften des entstandenen Tasks auszulesen? Dann erstelle ich den selbst.
    Danke!

    Antworten
    • Habe es natürlich dann gleich selbst gefunden: WinACME hat, direkt als Administrator gestartet, eine Option („O“) für „T: (Re)create scheduled task“. Das hat auch gleich funktioniert. :)

      Antworten
  10. Hi,

    danke für den Artikel. Wieder mal sehr aufschlussreich und einfach dargestellt.

    „–installation iis,script“ ist nicht notwendig. „–installation script“ ist ausreichend. Das Script weist aufgrund der Parameter „‚IIS,SMTP,IMAP,POP'“ ja eben auch den Webdiensten das Zertifikat zu.

    Sofern „–installation iis,script“ verwendet wird werden sogar zusätzliche Bindungen auf dem IIS für alle Hostnamen erstellt. Das ist meiner Ansicht nach nicht nur unschön sondern auch eine Änderung die zu sonderbaren Phänomenen führen kann.

    LG
    Timbo

    Antworten
  11. Hallo, ich habe alles wie in der Anleitung befolgt und Zertifikate für zwei DNS-Einträge erstellt.
    Im Exchange werden anders als hier gezeigt aber beide angezeigt: outlook.domäne.de und autodiscover.domäne.de, wobei beide 2 Monate gültig sind. Jedoch steht bei dem Autodiscover Zertifikat, dass dieser einen ungültigen Status hat.

    Habe ich da etwas falsch gemacht?

    Antworten
  12. bekomme es einfach nicht hin. Kann mir jemand weiterhelfen?

    A simple Windows ACMEv2 client (WACS)
    Software version 2.1.14.996 (RELEASE, TRIMMED, 64-bit)
    Connecting to https://acme-v02.api.letsencrypt.org/
    IIS version 10.0
    Running with administrator credentials
    Scheduled task not configured yet
    Please report issues at https://github.com/win-acme/win-acme
    Running in mode: Unattended
    Target generated using plugin Manual: mail.xxxx and 1 alternatives

    [mail.xxxx] Cached authorization result: valid
    [autodiscover.xxx] Authorizing…
    [autodiscover.xxx] Authorizing using http-01 validation (SelfHosting)
    [autodiscover.xxx] Authorization result: invalid
    [autodiscover.xxx] {
    „type“: „urn:ietf:params:acme:error:unauthorized“,
    „detail“: „Invalid response from http://autodiscover.xxxx/.well-known/acme-challenge/UBjaAZVN0cFR-h73KUlEYV0GWSrSaG9ERod9y60OfXk [2a01:238:20a:202:1082::]: \“\\n\\n404 Not Found\\n\\nNot Found\\n“Netzwerkdienst,Administratoren“
    Der Befehl „“Netzwerkdienst,Administratoren““ ist entweder falsch geschrieben oder
    konnte nicht gefunden werden.

    C:\Users\Administrator\Downloads\win-acme.v2.1.14.996.x64.trimmed>–installation iis,script –installationsiteid 1 –script
    Der Befehl „–installation“ ist entweder falsch geschrieben oder
    konnte nicht gefunden werden.

    C:\Users\Administrator\Downloads\win-acme.v2.1.14.996.x64.trimmed>“./Scripts/ImportExchange.ps1″

    Antworten
  13. Hallo zusammen,

    ich hatte vor ein paar Monaten auch auf win-scme am Exchange 2019 CU5 umgestellt. Jetzt wollte ich mal wieder auf das aktuelle CU7 Upgraden und laufe in folgenden Fehler:
    Fehler:
    Der folgende Fehler wurde generiert, als „$error.Clear();
    Install-ExchangeCertificate -services „IIS, POP, IMAP“ -DomainController $RoleDomainController
    if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
    {
    Install-AuthCertificate -DomainController $RoleDomainController
    }
    “ ausgeführt wurde: „Microsoft.Exchange.Management.SystemConfigurationTasks.AddAccessRuleUnauthorizedAccessException: Unzureichende Rechte zum Erteilen des Netzwerkdienstzugriffs auf das Zertifikat mit dem Fingerabdruck A3A9804DE68B129C811E4B7DC0149A989B4CC726. —> System.UnauthorizedAccessException: Certificate —> System.Security.Cryptography.CryptographicException: Der Schlüsselsatz ist nicht vorhanden.

    bei System.Security.Cryptography.Utils.CreateProvHandle(CspParameters parameters, Boolean randomKeyContainer)
    bei System.Security.Cryptography.Utils.GetKeyPairHelper(CspAlgorithmType keyType, CspParameters parameters, Boolean randomKeyContainer, Int32 dwKeySize, SafeProvHandle& safeProvHandle, SafeKeyHandle& safeKeyHandle)
    bei System.Security.Cryptography.RSACryptoServiceProvider.GetKeyPair()
    bei System.Security.Cryptography.RSACryptoServiceProvider..ctor(Int32 dwKeySize, CspParameters parameters, Boolean useDefaultKeySize)
    bei System.Security.Cryptography.X509Certificates.X509Certificate2.get_PrivateKey()
    bei Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.CAPIAddAccessRule(X509Certificate2 certificate, AccessRule rule)
    — Ende der internen Ausnahmestapelüberwachung —
    bei Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.CAPIAddAccessRule(X509Certificate2 certificate, AccessRule rule)
    bei Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.AddAccessRule(X509Certificate2 certificate, AccessRule rule)
    bei Microsoft.Exchange.Management.SystemConfigurationTasks.ManageExchangeCertificate.EnableForServices(X509Certificate2 cert, AllowedServices services, String websiteName, Boolean requireSsl, ITopologyConfigurationSession dataSession, Server server, List`1 warningList, Boolean allowConfirmation, Boolean forceNetworkService)
    — Ende der internen Ausnahmestapelüberwachung —
    bei Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
    bei Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
    bei Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.EnableForServices(X509Certificate2 cert, AllowedServices services)
    bei Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.InternalProcessRecord()
    bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
    bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)“.

    Der Fingerprint passt zu dem von win-acme erstellten Zertifikat im Lokalen Zertifikatsspeicher. Wie kann ich das Problem beheben? Hat da evtl. wer einen Tip?

    Danke im Voraus.
    LG Olli

    Antworten
    • Ok, habe den Fehler selber schon gefunden als ich das aktuelle Zertfikat per –renew –force neu austellen wollte:
      Unable to set full control rights for network service: Some or all identity references could not be translated.
      Unable to set full control rights for administrators: Some or all identity references could not be translated.

      Also win-acme nochamsl mit –acl-fullcontrol „netzwerkdienst,administratoren“ gestartet und danach auch erfolgreich das CU7 Update durchgeführt.

      Antworten
  14. Moin,
    wenn ich ein Zertifikat mit dem Tool erfolgreich erstellt habe, was super funktioniert hat, ich aber doch eine Adresse im Zertifikat vergessen habe, kann ich das Zertifikat einfach im EX2019 löschen und dann neu erstellen? Muss etwas beachtet werden?

    Antworten
  15. Hab das mit einem frischen Exchange 2019 auf Server 2019 ausprobiert. Mit dem alten Script lief das. Mit Win-Acme fehlt die Bindung für SMTP und der Server macht beim Test kein TLS mehr. Alte Script wieder ausgeführt, alles geht. Warum wurde SMTP nicht gebunden und wo kann ich die Kommunikation über TLS einstellen und ausprobieren, damit ich Port 80 wieder dicht machen kann?

    Antworten
    • Hab noch ein bisschen probiert: 1. Win-ACME kann das Zertifikat nicht an den Sendeconnector binden. Auch manuell über Frankys Anleitung (https://www.frankysweb.de/exchange-2016-smtp-connector-und-wildcard-san-zertifikate/) scheitert es, da das Zertifikat nicht für SMTP enabled ist. Manuelles enablen geht auch nicht.
      2. Alle Zertifikate gelöscht und Win-ACME nochmals laufen lassen. Gleiches Ergebnis: SMTP kann dem Zertifikat nicht zugewiesen werden.
      3. „Add full control for networkservice and administrators“ scheitert bei meinem Server 2019. Egal ob cmd als Admin oder normal. Vlt. kann mit den Angaben jemand etwas mehr anfangen.
      4. Der Testmode (–testmode –verbose) bringt mich leider auch nicht weiter.

      Antworten
  16. Danke für den Artikel,
    bei meinen ersten Tests lief die Zertifikat-Anforderung und Einbindung in einen Exchange 2016 im Staging und Live ohne grössere Probleme.
    Allerdings habe ich noch Warnungen im Log, auf die ich mir noch keinen Reim machen kann ( Ausführung lief mit Admin-Rechten)

    [INF] Adding certificate [Manual] autodiscover.danckelmann-kerst.de @ 2020.9.30 15:48:48 to store My
    [WRN] Unable to set full control rights for network service
    [WRN] Unable to set full control rights for administrators

    Anscheinend werden dem Zertifikat nicht alle vorgesehenen Rechte zugeordnet, hat schon jemand ne Idee woran das liegen mag?

    Antworten
      • Liegt sicherlich am deutschen Windows Server. Statt –acl-fullcontrol „network service,administrators“ solltet ihr –acl-fullcontrol „Netzwerkdienst,Administratoren“ verwenden

        Antworten
  17. Hi, in Verbindung mit der Sophos UTM benutze ich derzeit noch dein Script „Sophos UTM: Zertifikat der WAF mittels PowerShell exportieren“, welches bisher zuverlässig funktioniert :-)

    Nachdem ich plane, die Sophos UTM ggf. durch die Sophos XG Firewall zu ersetzen (die unterstützt ja bis heute kein Let’s Encrypt – anderes Thema…), habe ich mit der WIN-ACME zumindest für Exchange eine Alternative.
    Ich weiß nur noch nicht, ob Port 80 während der Zertifikatsanfrage/-Erneuerung Richtung Exchange-Server offen sein muss oder ob dies mit WIN-ACME hinfällig ist!?

    Antworten
    • Leider musste ich gestern feststellen, dass zwar meine ersten Test mit TLS liefen, aber im Zusammenhang mit dem Exchange Script immer wieder http vorgezogen wird. Auch nach Anpassung der settings Datei und zusätzlichem einfügen der unattended switches um den validatimode vorzugeben. Irgendwie scheint das Script da seinen eigenen Kopf zu haben. Leider bin ich dann gestern an die rate-limits gestoßen und muss heute noch drauf schauen. Im Moment ist win-acme für Exchange nur wie der alte Assistent über Port 80 lauffähig. Zumindest im unattended mode. Wenn man win-acme im voll manuellen Modus durchläuft geht es aber, da man hier den tls switch manuell setzen kann. Aber das Script jedesmal manuell neu zu konfigurieren ist auch nicht das Wahre.

      Antworten
  18. Danke für den Artikel!

    Nachdem ich nun seit fast einem Jahr auf eine überarbeitete, etwas robustere Version vom ECA warte freue ich mich, dass du dies mit uns teilst. Besonders interessant finde ich an win acme, dass man damit (scheinbar) auch die Möglichkeit hat ein Zertifikat für Exchange ohne Port 80 ausstellen zu lassen (tls-alpn-01), was mir im Jahr doch einiges an Arbeit ersparen würde, wenn es so funktioniert wie ich das verstanden habe.

    Ich würde hier noch einmal einen Kommentar verfassen sobald ich dies erfolgreich zum laufen gebracht habe.

    Antworten
  19. Danke für den Artikel!

    Vor dem Umstieg interessiert mich natürlich die Fragen, wie das mit einem bereits bestehenden Konto bei LE ist, wenn man bisher deinen Assistenten verwendet hat. Beim ersten Ausführen muss ja eine Email Adresse angegeben werden. Läuft das problemlos durch, wenn man die selbe Email Adresse eingibt, wie beim Certificate Assistant? Hast du das mal getestet?

    Vielen Dank!

    Antworten
    • Hab mir die Frage schon selber beantwortet. Zum Glück hat das Tool einen Test Modus :D

      Lief zumindest im Test Problemlos durch. Auch über TLS. Dann muss ich nicht immer Port 80 jedes mal öffnen :)

      Antworten

Schreibe einen Kommentar