Debian: Webserver mit vhosts (virtuellen Webservern)

Debian: Webserver mit vhosts (virtuellen Webservern)

Einen Webserver unter Debian zu installieren ist nicht besonders schwer, hier eine kurze Anleitung.

Beachten Sie jedoch dringend noch folgende Ratschläge:

  • Stellen Sie ihr System so ein, das es sich automatisch aktuell hält oder halten Sie ihr System aktuell.
  • Stellen Sie ihren Server nicht direkt ins Internet, nutzen Sie eine Firewall davor und veröffentlichen Sie nur die entsprechend benötigten Dienste.
  • Wählen Sie komplexe Kennwörter.
  • Erlauben sie keinen direkten Root Zugriff.
  • Setzen Sie Richtlinien zum härten ihres Webservers um.

Los geht:

Downloaden sie die aktuelle Version (derzeit 9.3) Netzwerkinstall herunter und kopieren Sie sie in einen Datenspeicher auf dem Host.

Erstellen Sie eine VM (z.B. Version 6.5, 4 Porzessoren, 8 GB Ram, 60 GB Thin, Netzwerkkarte, CD Laufwerk mit dem entsprechenden ISO).

Starten Sie die Installation (z.B. alles abgewählt bis auf SSH Server und Systemtools).

Nach der Installation loggen Sie sich ein mit dem erstellten User und holen sich die IP mit „ip addr show“.

Verbinden Sie sich mit SSH (unter OSX oder *nix mit Terminal oder unter Windows mit z.B. Putty) und wecheln sie zu root mit „su“.

Nun werden wir dem Server eine feste IP zurordnen:

cd /etc/network/interfaces

Editieren Sie den folgenden Eintrag (z.B. mit VI oder Nano):

iface ens192 inet dhcp (Achtung, statt ens192 kann hier auch was anderes stehen wie z.B. eth0)

Ändern sie ihn wie folgt (verwenden Sie bitte natürlich ihre eigenen Daten):

iface ens192 inet static
address 192.168.123.10/24
gateway 192.168.123.254
dns-nameservers 192.168.123.254
dns-search domain.tld

Starten Sie die Installation vom Webserverteil wie folgt:

apt-get update
apt-get upgrade
apt install apache2 apache2-utils

Wenn Sie ihre Seite mit SSL sichern wollen (ich verwende mittlerweile oft ssls.com, dort bekommt man ein einfaches Zertifikat für ca. 15$ für 3 Jahre und dies erhält man in wenigen Minuten), gehen Sie wie folgt im Terminal vor:

cd /etc/ssl/private
openssl genrsa -out servername.domain.tld.key 2048
openssl req -new -key servername.domain.tld.key -out servername.domain.tld.csr -sha256

Dieses CSR verwenden Sie bitte um das Zertifikat zu beantragen. Ich hole es mir einfach in dem ich folgendes im Terminal eingebe:

cat servername.domain.tld.csr

Dieses dann rauskopieren zum beantragen.

Sollten Sie das Zertifikat haben, benötigen Sie das entsprechend auf dem Server. Dazu muss der inhalt vom servername.domain.tld.crt und servername.domain.tld.ca-bundle auf dem Server in eine Datei servername.domain.tld.crt kopiert werden – dies mache ich mit dem VI:

vi servername.domain.tld.crt

i drücken, den Inhalt aus servername.domain.tld.crt reinkopieren und in der nächsten Zeile dann den Inhalt aus servername.domain.tld.ca-bundle und das ganze dann mit „ESC“, „:wq“ speichern.

Nun die Rechte anpassen:

chown root:ssl-cert servername.domain.tld.*

Dann noch die Zertifikate in /etc/apache2/sites-available/default-site.conf ändern auf die neuen Dateien:

SSLCertificateFile /etc/ssl/private/servername.domain.tld.crt
SSLCertificateKeyFile /etc/ssl/private/servername.domain.tld.key

Nun die alte Site entladen, die neue laden und danach die Konfiguration neuladen – sollte Apache danach immer noch keine SSL Seite zeigen, noch mal den Dienst neu starten:

a2dissite default-ssl.conf

a2ensite defaultssl.conf

systemctl reload apache2

systemctl restart apache2

Habt ihr nun den Namen des Servers schon im DNS oder mindestens in der Hosts eingerichtet, so könnt ihr schon den Server aufrufen. Vergesst auch bitte nicht in der Firewall den Port forzuwarden (Port 80 und 443).

Möchte man später mehrere virtuelle Webserver auf dem Server installieren empfiehlt es sich schon jetzt die Verzeichnisse entsprechend anzupassen:

cd /var/www

mkdir ordnername

chown -R www-data:www-data ordnername

chmod -R 755 ordnername

Dann noch die Ordnerpfade und eigene Adminemailadresse anpassen in der /etc/apache2/sites-available/000-default-site.conf und default-ssl.conf und wieder die Sites neulade sowie den Apache:

a2dissite 000-default.conf

a2dissite default-ssl.conf

a2ensite 000-default.conf

a2ensite default-ssl.conf

systemctl reload apache2

Nun kommt die PHP Installation:

apt install php7.0 libapache2-mod-php7.0 php7.0-mysql php-common php7.0-cli php7.0-common php7.0-json php7.0-opcache php7.0-readline

a2enmod php7.0

a2enmod rewrite

systemctl restart apache2

Kontrolliert nun ob PHP funktioniert – erstellt z.B. in dem Ordner oben eine Datei index.php mit dem folgenden Inhalt:

<?php
phpinfo();
?>

Sollten Sie nun auch ihre Seite nur noch über HTTPS aufrufen wollen, dann können sie in dem Verzeichnis eine Datei .htaccess erstellen mit folgenden Inhalt:

<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] </IfModule>

Anschließend noch mal die Rechte anpassen:

chown -R www-data:www-data ordnername

chmod -R 755 ordnername

Weiterhin muss noch /etc/apache2/sites-available/000-default.conf erweitert werden (unterhalb von Documentroot) mit dem folgendem Eintrag:

<Directory /var/www/servicecenter>
 Options Indexes FollowSymLinks MultiViews
 AllowOverride All
 Order allow,deny
 allow from all
</Directory>

Weiterhin muss noch /etc/apache2/sites-available/000-default.conf erweitert werden (unterhalb von Documentroot) mit dem folgendem Eintrag:

<Directory /var/www/servicecenter>
 Options Indexes FollowSymLinks MultiViews
 AllowOverride All
 Order allow,deny
 allow from all
</Directory>
<FilesMatch "\.(cgi|shtml|phtml|php)$">
 SSLOptions +StdEnvVars
</FilesMatch>

Anschließend müssen natürlich wieder die Konfigurationen neu geladen werden:

a2dissite 000-default.conf

a2dissite default-ssl.conf

a2ensite 000-default.conf

a2ensite default-ssl.conf

systemctl reload apache2

Rufen Sie die Seite auf und kontrollieren Sie bitte ob die Seite erreichbar ist und auch PHP funktioniert. Löschen Sie bitte jedoch nach der erfolgreichen Installation wieder die Datei index.php oder ändern sie den Inhalt , da sie viele Informationen über ihr System preisgibt.

Nun installieren wir den SQL Server, statt MySQL wird jedoch mittlerweile MariaDB verwendet, welches kompatibel ist jedoch Open Source und somit frei zur Nutzung. Mit dem weiteren Befehl machen wir MariDB zum Standard und anschließend kontrollieren wir ob der Server gestartet ist. Starten Sie dazu wieder im Terminal wie folgt:

apt install mariadb-server mariadb-client

apt install mysql-server mysql-client

systemctl status mariadb

Nachdem der Server läuft, kommen die Nacharbeiten (Autostart einrichten und Security härten):

systemctl enable mariadb

mysql_secure_installation

Wollte ihr mehrere Seiten auf dem Server hosten, erstellt bitte pro Seite einen Ordner:

cd /var/www
mkdir ordnername
chown -R www-data:www-data ordnername
chmod -R 755 ordnername

Passt wieder in /etc/apache2/sites-available die Dateien wie folgt an:

Default-ssl.conf

<IfModule mod_ssl.c>
<VirtualHost *:443>
 SSLEngine on
 SSLCertificateFile /etc/ssl/private/seite1.crt
 SSLCertificateKeyFile /etc/ssl/private/seite1.key

 Servername "www.seite1.de"
 ServerAlias "seite1.de"
 DocumentRoot "/var/www/seite1"
 ServerAdmin admin@seite1.de
 ErrorLog ${APACHE_LOG_DIR}/ssl-error.log
 CustomLog ${APACHE_LOG_DIR}/ssl-access.log combined
 <Directory /var/www/seite1>
 Options Indexes FollowSymLinks MultiViews
 AllowOverride All
 Order allow,deny
 allow from all
 </Directory>
 <FilesMatch "\.(cgi|shtml|phtml|php)$">
 SSLOptions +StdEnvVars
 </FilesMatch>
 <Directory /usr/lib/cgi-bin>
 SSLOptions +StdEnvVars
 </Directory>
 BrowserMatch "MSIE [2-6]" \
 nokeepalive ssl-unclean-shutdown \
 downgrade-1.0 force-response-1.0
 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
 </VirtualHost>

 <VirtualHost *:443>
 SSLEngine on
 SSLCertificateFile /etc/ssl/private/seite2.crt
 SSLCertificateKeyFile /etc/ssl/private/seite2.key

 Servername "www.seite2.de"
 ServerAlias "seite2.de"
 DocumentRoot "/var/www/seite2"
 ServerAdmin admin@seite2.de
 ErrorLog ${APACHE_LOG_DIR}/seite2-ssl-error.log
 CustomLog ${APACHE_LOG_DIR}/seite2-ssl-access.log combined
 <Directory /var/www/seite2>
 Options Indexes FollowSymLinks MultiViews
 AllowOverride All
 Order allow,deny
 allow from all
 </Directory>
 <FilesMatch "\.(cgi|shtml|phtml|php)$">
 SSLOptions +StdEnvVars
 </FilesMatch>
 <Directory /usr/lib/cgi-bin>
 SSLOptions +StdEnvVars
 </Directory>
 BrowserMatch "MSIE [2-6]" \
 nokeepalive ssl-unclean-shutdown \
 downgrade-1.0 force-response-1.0
 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
 </VirtualHost>
</IfModule>

000-default.conf

<VirtualHost *:80>
 ServerName www.seite1.de
 ServerAlias seite1.de
 ServerAdmin admin@seite1.de
 DocumentRoot /var/www/seite1/
 <Directory />
 Options FollowSymLinks
 AllowOverride None
 </Directory>
 <Directory /var/www/seite1>
 Options Indexes FollowSymLinks MultiViews
 AllowOverride All
 Order allow,deny
 allow from all
 </Directory> ErrorLog /var/log/apache2/error.log
 LogLevel warn
 CustomLog /var/log/apache2/access.log combined
</VirtualHost>
<VirtualHost *:80>
 ServerName www.seite2.de
 ServerAlias seite2.de
 ServerAdmin admin@seite2.de
 DocumentRoot /var/www/seite2/
 <Directory /var/www/seite2>
 Options Indexes FollowSymLinks MultiViews
 AllowOverride All
 Order allow,deny
 allow from all
 </Directory>
 ErrorLog /var/log/apache2/seite2-error.log
 LogLevel warn
 CustomLog /var/log/apache2/seite2-access.log combined
 ServerSignature On
</VirtualHost>

Danach natürlich wie immer alles entladen und neuladen:

a2dissite 000-default.conf

a2dissite default-ssl.conf

a2ensite 000-default.conf

a2ensite default-ssl.conf

systemctl reload apache2

Widmen wir uns nun dem Teil der Datenübertragung – dies realisieren wir mit ProFTP. Da der Server in der DMZ steht und nur meine eigenen Seiten gehostet werden sowie nur über VPN Zugegriffen wird werde ich das Documentroot auf /var/www/ stellen, da ich dort alle Seiten anlege und kein TLS verwenden. Der Server übers Internet nur über HTTP und HTTPS veröffentlicht. SSH, FTP und SQL wird nur über verschlüsseltes VPN genutzt.

apt-get install proftp

Datei /etc/proftpd/conf.d/custom.conf erstellen (bei benutzername bitte den Namen des Zugriffkontos eintragen, nicht root):

<Global>
 RequireValidShell off
</Global>
# If desired turn off IPv6
UseIPv6 off
# Default directory is ftpusers home
DefaultRoot /var/www benutzername
# Limit login to the ftpuser group
<Limit LOGIN>
 DenyGroup !ftpuser
</Limit>

Gruppe ftpuser und www-data hinzufügen, Benutzer hinzufügen und Dienst neustarten:

addgroup ftpuser

usermod -a -G ftpuser benutzername

usermod -a -G www-data benutzername

systemctl restart proftpd

Solltet ihr Dateien nicht löschen oder ändern können, so kontrolliert bitte die Rechte und passt diese gegebenenfalls an mit:

chown -R benutzername /var/www/ordnername

chmod -R 755 /etc/www/ordnername

Somit ist der Server bereitgestellt und einsatzbereit.

Erweiterung: Python installation

Kontrollieren Sie ob Python installiert ist und in welcher Version:

python3 --version

Installieren Sie noch PIP und binden Sie Python in Apache ein:

apt-get install python3-pip

pip3 install mod_wsgi

apt-get install libapache2-mod-python

Nun muss noch der Publisher Handler eingerichtet werden – diese werden wieder in den Sitekonfigurationen erstellt – erweitert dazu die 000-default.conf und default-ssl.conf unterhalb des bestehenden der:

<Directory /var/www/seite1>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
AddHandler mod_python .py
PythonHandler mod_python.publisher
PythonDebug On
</Directory>

Anschließend wieder die Sites und Apache neu laden:

a2dissite 000-default.conf

a2dissite default-ssl.conf

a2ensite 000-default.conf

a2ensite default-ssl.conf

systemctl reload apache2

Weitere Schritte folgen noch …

 

 


Sophos XG eigenes öffentliches Zertifikat verwenden

Um keine Fehlermeldungen zu erhalten beim Zugriff auf die Adminöberfläche  oder dem Userportal der Firewall setze ich ein öffentliches Zertifikat ein. Da ich das jedoch meistens nur selber nutze, reicht mir ein günstiges einfaches mit einer niedrigen Sicherheitsstufe aus.

Dazu verwende ich die SSL Zertifikate von SSLs.com – diese gibt es für ca. 15€ für 3 Jahre, das sind rund 0,42€ pro Monat.

Da ich nun von der Sophos UTM auf die Sophos XG umstelle, beschreibe ich hier den Weg wie man ein solches Zertifikat einrichtet, was unter der XG wesentlich einfacher geht als unter der UTM.

Als erstes müssen wir ein CSR erstellen, dazu gehen wir in der XG nach Certificates > Certificates > Add und erstellen folgenden CSR:

Da die Daten auch über das fertige Zertifikat einzusehen sind, habe ich die originalen Daten gelassen, ihr tragt da natürlich eure eigenen Daten ein. Da ich schon ein Zertifikat habe und das nur änder (was kostenlos ist bei SSLs.com) übernehme ich oben natürlich das originale Ablaufdatum.

Wenn ihr die Einstellungen bestätigt habt, könnt ihr dann das Zertifkat herunterladen (welches als GZ und TAR komprimiert ist, mit dem kostenlosen 7Zip könnt ihr diese entpacken).

Auf SSLS.com „kauft“ ihr dann das Zertifikat und verwendet das eben entpackte CSR.

Nun müsst ihr noch die Dateien zusammenbauen mit OpenSSL, dazu könnt ihr dann unter Windows OpenSSL installieren, auf einem Mac habt ihr das schon drauf. Dazu verwendet ihr den folgenden Befehl:

openssl pkcs12 -export -in url_domain_de.crt -inkey url_domain_de.key -out url_domain_de.p12

Mit dem neu erstellten Zertifikat könnt ihr nun in der Sophos XG das neue Zertifikat einfügen:

Dieses könnt ihr dann nun unter Administration > Port Settings for Admin Console > Certificate zurordnen.


Windows Server 2016: Mehrere SSL Zertifikate auf einer IP

Mehrere SSL Zertifikate mit mehreren verschiedenen Namen und Zertifikaten auf der selben Seite zu verwenden (statt z.B. einem SAN Zertifikat für Exchange Server) kann man in dem Windows Server 2016 bequem über den Internetinformationdienste (IIS) – Manager einrichten.

Dazu gehen Sie wie folgt vor:

  • Starten Sie den Internetinformationdienste (IIS) – Manager.
  • Gehen Sie links auf den Servernamen.
  • Rechts klicken Sie auf Serverzertifikate und rechts dann auf Zertifikatsanforderungen.
  • Besorgen Sie sich nun ein Serverzertifkat (z.B. PSW.net oder SSLs.com) und spielen Sie dies ein.
  • Gehen Sie nun links auf die entsprechende Site mit der rechten Maustaste und wählen Bindungen aus.
  • Gehen Sie nun auf Hinzufügen und wählen Sie https aus, geben die neue URL ein, Port 443 und das entsprechende Zertifikat, bitte unbedingt auch den Haken bei SNI setzen.
  • Speichern Sie nun die Einstellungen und testen Sie diese, sollte es nicht klappen können Sie den IIS mit iisreset in einer privilegierten CMD Console neustarten .

ESXI 6.5 (Free) mit öffentlichen Zertifikat ausstatten

Da der ESXI nun mit einem Webinterface ausgestattet ist, welches mittlerweile gut unter OSX funktioniert, möchte ich gerne komfortabler und sicherer auf das Webinterface zugreifen.

Dazu möchte ich gerne den Server mit einem gültigen öffentlichen 3 Jahres Zertifikat von Comodo ausstatten, welches ich auf meinem Exchange Server verwende. Dieses habe ich für ca. 15€ für insgesamt 3 Jahre über https://www.ssls.com bezogen.

Das ganze gestaltete sich jedoch schwieriger als ich dachte und ich war froh darüber, das ich Support vom VMWare-Forum bekommen hatte – hier besonderen Dank an ~thc, irix und mbreidenbach.

Vorbereitend benutzte ich einen Windowsrechner, wo ich OpenSSL 32 Bit installierte und mir dort einen Key und ein CSR erstellte, welches ich zertifizieren ließ und anschließend auf dem ESXI Host an die entsprechende Stelle brachte.

Dazu ging ich wie folgt auf dem Windowsrechner vor:

  • In das Verzeichnis C:\OpenSSL\bin wechseln
  • Die openssl.cfg weg sichern und den Inhalt ersetzen wie hier (Rot durch eigene Werte ersetzen):
[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:esxi, IP:192.168.99.1, DNS:esxi.leibling.de

[ req_distinguished_name ]
countryName = DE
stateOrProvinceName = Northrhine-Westfalia
localityName = Koeln
0.organizationName = Familie Leibling
organizationalUnitName = EDV
commonName = esxi.leibling.de
  • Den folgenden Befehl starten: openssl req -nodes -new -newkey rsa:4096 -sha512 -keyout rui.key -out rui.csr -config openssl.cfg
  • Die rui.key benötigen wir später, aus dem rui.csr erstellen wir beim Zertifizieren einen Zertifikatsantrag.
  • Wenig später sollte das fertige Zertifikat per Email zugesendet werden.
  • Die Zipdatei Entpacken wir und wechseln auf der Befehlszeile in das Verzeichnis und geben dort folgenden Befehl ein (alles in einer Zeile, sollte euer Browser hier mehrere Zeilen erstellen, bitte diese zusammenführen): cat esxi_domain_de.crt COMODORSADomainValidationSecureServerCA.crt
    COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > combined.crt
  • Bei mir war nun das Problem, das dieses Zertifikat im PKCS7-Format war und nicht wie benötigt im pem-Format (konnte man in der ersten Zeile erkennen wenn man die Datei in einem Texteditor öffnete) – die Lösung hier sollte sein, das man die combined.crt in das Verzeichnis C:\OpenSSL\bin kopiert und den folgenden Befehl eingibt – sollte die Datei schon im pem-Format gewesen sein, muss sie nur noch in rui.crt umbenannt werden. Der Befehl für die Konvertierung lautet: openssl pkcs7 -in combined.crt -print_certs -out rui.crt
  • Nun schalten Sie auf dem ESXI SSH ein und erstellen Sie in einem Datastore einen Ordner ZERTIFIKATE. Laden Sie nun die Datei rui.crt und rui.key in den Ordner.
  • Gehen Sie mit SSH auf den ESXI (z.B. unter Windows mit Putty oder unter OSX direkt im Terminal mit ssh ipadresse -lroot und verbinden sich zum ESXI.
  • Gehen Sie in das Verzeichnis /etc/vmware/ssl und benennen Sie die Datei rui.crt und key.key um (z.B. mv rui.crt rui.crt.save und mv rui.key rui.key.save).
  • Kopieren sie nun die neuen Dateien an den Ort (cp /vmfs/Volumes/datastorename/ZERTIFIKATE/rui.* ./ – beachten Sie bitte, das Linux Groß- und Kleinschreibung unterscheidet).
  • Starten Sie den Webdienst neu (/etc/init.d/rhttpproxy restart).

Achtung: Sollten Sie eine Fehlermeldung erhalten, welche anzeigt das die Seite nicht geöffnet werden kann – sollten Sie unbedingt wieder die neuen Dateien umbenennen in z.B. rui.crt.new bzw. rui.key.new und die gesicherten *.save Dateien wieder zurück nennen und starten Sie den Dienst neu.

Ich hatte dies im ersten Durchgang nicht so getan und musste dummerweise den gesamten ESXI auf Werkseinstellungen zurücksetzen – zwar bleiben die VM’s dabei erhalten, jedoch war einer der Datastore der unter ESXI 6.0 erstellt war nicht mehr im Zugriff (diesen konnte ich auch nicht mit der Webgui wieder bekannt machen, sondern musste auf den VMWare Client zurückgreifen) und alle andern Informationen wie Netze, Autostartkonfigurationen, Lizenzen usw. waren weg. Zusätzlich waren keine VMs mehr registriert.

Übrigen läßt sich mit einem iPad wunderbar die Webgui bedienen – inklusive der VMs 😉 :

Links:


Windows: Eigenes RDP Zertifikat verwenden

Tags :

Kategorie: Allgemein , Diverse , Server , Support

Wenn man ein eigens Zertifikat hat, wie z.B. eins für Exchange/OWA, dann kann man dieses ebenfalls dem RDP Dienst zuordnen – so erhält man keine Ferhlermeldung beim Remotezugriff per RDP.

Unter Windows Server 2008 (R2) ging es noch einfach mit der GUI, aber Server 2012 jedoch nicht mehr, dies kann man jedoch mit der Powershell anpassen.

Dazu eine MMC erstellen mit dem SnapIn Zertifikate (Computerkonto) und dort dann das bestehende Exchangezertifikat in die Kategorie Remotedesktop kopieren.

Das bestehende Zertifikat abfragen mit dem folgenden Befehl:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Get SSLCertificateSHA1Hash

Dann das Exchangezertifikat in der MMC öffnen und aus den Eigenschaften den Thumbprint kopieren.

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash=thumbprint

Statt Thumbprint geben Sie den Thumbprint aus den Eigenschaften ein, ohne Leerzeichen.

Starten Sie die Remotedesktopdienste neu – sollten sie immer noch eine Fehlermeldung erhalten, starten Sie bitte den Server neu.

Quelle: http://www.it-training-grote.de/download/RDS-2012R2-SelfSignedCertificate.pdf


Exchange 2010/2013/2016 ohne SAN Zertifikat betreiben

Sollte man von einem SAN Zertifikat umsteigen auf ein herkömmliches Zertifikat, so muss man auch noch einige Einstellungen im Exchange vornehmen, damit keine Fehlermeldungen mehr erscheinen beim öffnen von Outlook usw.

Vorbereitungen:

  • In der ECP die externe Adresse unter Nachrichtenfluss > Akzeptierte Domänen einrichten.
  • Danach in der ECP unter Nachrichtenfluss > E-Mail-Adressrichtlinie die Default Policy bearbeiten mit der externen Adresse und Anwenden.
  • Im Internen DNS (AD-DNS und DNS für die echte Emailadresse) sowie im Externen DNS folgendes einrichten:
    • Hosteintrag auf dem das Zertifikat läuft
    • CNAME von autodiscover auf die Zertifikatsadresse.
    • Servicerecord erstellen mit den folgenden Werten:

Service: _autodiscover
Protokoll: _tcp
Priorität: 0
Gewichtung: 0
Port: 443
Host: Adresse des Hostes auf dem das Zertifikat läuft

Danach müssen in der Exchange Management Shell folgende Änderungen vorgenommen werden:

Set-ClientAccessServer -Identity servername -AutoDiscoverServiceInternalUri “https://exchange.domain.de/Autodiscover/Autodiscover.xml”

Set-AutodiscoverVirtualDirectory -Identity “servername\Autodiscover (Default Web Site)” -InternalUrl “https://exchange.domain.de/Autodiscover/Autodiscover.xml” -ExternalUrl “https://exchange.domain.de/Autodiscover/Autodiscover.xml”

Set-WebServicesVirtualDirectory -Identity “servername\EWS (Default Web Site)” -InternalUrl “https://exchange.domain.de/EWS/Exchange.asmx” -ExternalUrl “https://exchange.domain.de/EWS/Exchange.asmx”

Set-OWAVirtualDirectory -Identity “servername\OWA (Default Web Site)” -InternalUrl “https://exchange.domain.de/owa” -ExternalUrl “https://exchange.domain.de/owa”
Set-ECPVirtualDirectory -Identity “servername\ECP (Default Web Site)” -InternalUrl “https://exchange.domain.de/ecp” -ExternalUrl “https://exchange.domain.de/ecp”
Set-ActiveSyncVirtualDirectory -Identity “servername\Microsoft-Server-ActiveSync (Default Web Site)” -InternalUrl “https://exchange.domain.de/Microsoft-Server-Activesync” -ExternalUrl “https://exchange.domain.de/Microsoft-Server-Activesync”
Set-MapiVirtualDirectory -Identity „servername\mapi (Default Web Site)“ -InternalUrl https://exchange.domain.de/mapi -ExternalUrl https://exchange.domain.de/mapi -IISAuthenticationMethods NegotiateSet-OABVirtualDirectory -Identity “servername\OAB (Default Web Site)” -InternalUrl “https://exchange.domain.de/OAB” -ExternalUrl “https://exchange.domain.de/OAB”
Enable-OutlookAnywhere -Server servername -ExternalHostname “exchange.domain.de” -ClientAuthenticationMethod “Basic”-SSLOffloading:$False

Weitere Infos:


SBS: Internes Zertifikat abgelaufen, wie erneuern?

Obwohl Zertifikate sehr günstig mittlerweile zu bekommen sind (z.B. Thawte 3 Jahres Zertifikat für 99€ inkl. MwSt.) verwenden einige Kunden doch lieber das vom SBS selber erstellte Zertifikat.

Dieses läuft noch alle 2 Jahre ab.

Um wieder eine neues ausgestellt zu bekommen, muss einfach der Assistent „Internetadresse einrichten“ ausgeführt werden in der Small Business Server Konsole (Netzwerk > Konnektivität > Internetadresse einrichten).