Exchange 2010 hibrid, SMTP, SSL tanúsítványok és alany alternatív nevei

Minden Exchange-kiszolgálón szüksége van SSL-tanúsítványokra hitelesítési, érvényesítési és titkosítási célokra. SMTP-hez használhatja az önaláírt tanúsítványt. Az Exchange 2010 opportunista TLS-t használ, így ebben a forgatókönyvben az önaláírt tanúsítvány megteszi. Ha tartománybiztonságot (kölcsönös TLS-t) kell konfigurálnia az Exchange szolgáltatásban, ehhez megfelelő, harmadik féltől származó SSL-tanúsítványra van szüksége.

Az Office 365 és az Exchange közötti SMTP-kommunikáció hibrid forgatókönyvben a kölcsönös TLS vagy tartománybiztonság egyik példája. Megfelelő, harmadik féltől származó SSL-tanúsítványra van szükség az Exchange-kiszolgálón.

Mindig az volt a benyomásom, hogy a kölcsönös TLS csak a tanúsítvány közös nevét használhatja, ami az én forgatókönyvemben a CN=webmail.inframan.nl. Egy korábbi blogbejegyzés után érdekes vita alakult ki ezzel kapcsolatban (lásd az adott blogbejegyzés kommentjeit), így most itt az ideje egy kis tesztelésnek.

Eredetileg rendelkeztem egy Digicert SSL-tanúsítvánnyal CN=webmail.inframan.nl köznévvel és egy tárgy alternatív név bejegyzésével: autodiscover.webmail.com. A HCW során beléptem a webmail.inframan.nl címre, és kiválasztottam a megfelelő tanúsítványt.

Ideje volt megújítani az SSL-tanúsítványomat, ezért hozzáadtam egy további SAN-bejegyzést: o365mail.inframan.nl.

Amikor ismét futtatom a Hibrid konfigurációs varázslót az Exchange 2010 szerveremen, kiválasztom a megfelelő SSL-tanúsítványt:

És beírta a további FQDN-t o365mail.inframan.nl:

A csatlakozási szoftver érvényesítése sikeresen megtörténik, de ha alaposan megnézi, továbbra is a régi webmail.inframan.nl FQDN-t használja.

Itt várnám az új FQDN-t, de úgy tűnik, a HCW nem konfigurálja újra az Office 365 fogadási csatlakozót az Exchange 2010-en. Még mindig be van állítva a webmail.inframan.nl címre:

Tehát, miután megváltoztatta az o365mail.inframan.nl-re:

Az érvényesítési folyamat ismét sikeres volt, de most az o365mail.inframan.nl FQDN-t (és az SSL-tanúsítvány SAN bejegyzését) használja az Office 365 és az Exchange 2010 közötti levelezéshez:

Tehát korábbi meggyőződésemmel ellentétben nincs szükség külön SSL-tanúsítványra egy további FQDN-hez, hanem használhat egy további SAN-bejegyzést a meglévő SSL-tanúsítványon.

A hibrid telepítésekre vonatkozó tanúsítványkövetelményekről itt talál további információt: https://technet.microsoft.com/en-us/library/hh563848(v=exchg.141)

Miért akarod ezt egyáltalán használni?

Egy vagy két Exchange 2010-es szerver használatakor nincs értelme, de van olyan ügyfelem is, akinek 28 Exchange 2010-es szervere fut 40.000 postaládával, és itt szeretnénk elkülöníteni az Office 365 SMTP forgalmat a normál SMTP forgalomtól. A tanúsítványokat tekintve egyszerűbb csak egy SSL-tanúsítványt fenntartani egy további SAN-bejegyzéssel, majd egy további SSL-tanúsítványt egyetlen domain névvel.

Külön köszönet 'Trekveer Harry'-nek, hogy ebbe az irányba mutatott ?