1. november kommer - Er Exchange Server klar?

1. november 2015: Nye regler trer i kraft

Vennene dine på SSL.com vil gjerne fortelle deg den begynnelsen November 1st, 2015, Noen veldig viktige endringer angående hva som kan dekkes i SSL-sertifikater trer i kraft:

• Nye sertifikater som inneholder interne navn vil ikke lenger bli utstedt av noen sertifikatmyndighet i henhold til retningslinjene for CA / Browser Forum (dvs. alle anerkjente)
  
  Merk at SSL.com i noen tid ikke har utstedt intranett-sertifikater til interne navn med utløpsdatoer etter 1. november 2015, og SSL.com-kunder bør derfor ikke støte på noen umiddelbare problemer, men vi oppfordrer deg sterkt til å dobbeltsjekke sertifikatene dine. for potensielle måter disse kjennelsene kan påvirke deg.
• Eksisterende sertifikater som inneholder interne navn vil ikke bli utstedt på nytt etter 1. november 2015.
  
  Igjen, SSL.com har jobbet for å sikre at du ikke får problemer på grunn av dette - men vi har presentert et worst-case scenario for din oppbygging nedenfor.
• Eksisterende sertifikater som inneholder interne navn tilbakekalles AUTOMATISK 1. november 2016.
  
  Dette er en omfattende politikk, siden noen sikkerhetsarkitekturer kan ha lange eksisterende arvsertifikater som ikke overholder disse reglene.

Disse endringene betyr at e-post - internettets første og fremdeles mest nyttige verktøy - kan påvirkes negativt av endringer, spesielt hvis du bruker Microsofts Exchange Server (som markedsundersøkelser antyder er 63 prosent av alle). Dermed kan sikkerhetsarkitekturen din bli påvirket fra og med den kommende All Saint's Day.

Er du klar?

Hva mener du når du sier "interne navn"?

Den enkleste definisjonen av et internt navn er hvilken som helst nettverksidentifikator del av et privat nettverk og ikke tilgjengelig med et navn ved bruk av et toppnivådomene (TLD) eller unik IP-adresse. Implikasjon, enhver nettverks-ID som er offentlig registrert hos en sentral myndighet som ICAAN, kan brukes i sertifikater

I de tidligere, enklere dagene på internett måtte en intern DNS-arkitektur bare bekymre seg for å unngå et begrenset sett med TLD-er - dermed kunne AwfulBigCo.coms intranett ikke bare støtte ABC.nyc og ABC.london men 1600. Pennsylvania.ave, post og Gandalf. Dessuten, noen IPv4- og IPv6-adresser er satt av for rent lokal bruk - disse reserverte områdene inkluderer "192.168. *. *" for ruting og 10. *. *. * for lokale nettverk. Å sikre intranett med SSL-sertifikater er selvfølgelig en god idé, og inntil den nye kjennelsen kan enhver nettverksadministrator be om og motta et sertifikat som inkluderer noen av disse.

Fra 1. november 2015 vil dette ikke lenger være tilfelle - sertifikater vil ikke lenger bli utstedt - eller, avgjørende, RE-utstedt - som inneholder interne navn. Disse nye reglene er designet for både å forbedre sikkerheten og tillate riktig bruk av nye toppnivå domenenavn (for eksempel er både .london og .nyc offentlige TLD-er nå). Imidlertid krever de at alle Exchange-brukere ser nøye på nettverks- og sikkerhetsoppsettet og gjør endringer for å anerkjenne disse nye reglene. Siden mange Exchange-sikkerhetsdesigner historisk har brukt interne navn, kan dette føre til alvorlige problemer med e-posttjenesten din når og når sertifikatene dine utløper, siden nye sertifikater med interne navn ikke kan utstedes for å erstatte dine eksisterende - verre, noe multi-domain-sertifikat inneholder bare ett internt navn mislykkes ved fornyelse, og potensielt utsetter e-posttrafikken din for ondsinnede utnyttelser.

Hvis du ikke gjør dette, kan det påvirke e-posttrafikken din, virksomheten din og / eller omdømmet ditt negativt.

Høres dyster ut.

Det kan veldig godt være - det kommer virkelig an på hvor forberedt du er. Dette kan være et veldig enkelt problem å gå glipp av, og konsekvensene kan være helt fatale for virksomheten din - if du klarer ikke å handle i forkant.

Se, AwfulBigCos sertifikatleverandør kjørte forespørselen forbi robotene sine, oppdaget de interne navnene og (i henhold til CA / B-forumets regler) avviste fornyelsen.

Dette er et problem. UCC vil IKKE fornyes, og ikke bare vil tjenester som bruker de tillatte interne navnene (dvs. all firmapost og FTP-sikkerhetskopier) ikke lenger være beskyttet - heller ikke ANDRE domener som er inkludert i UCC, som primær og .co. uk domener for AwfulBigCo.

Visst, dette er et ekstremt worst case-scenario - men vi tror virkelig at full sikkerhet avhenger av å forberede seg på akkurat det.

Ok, jeg er Legit Scared - Hva gjør jeg nå?

Hvis du bruker interne navn i SSL-sertifikatene dine, MÅ du ta tiltak for å løse dette, og jo før jo bedre.

I utgangspunktet er det noen få alternativer du kan velge:

1. Konfigurer systemet på nytt for bare å bruke offentlig registrerte domenenavn.
   Dette er trolig den beste løsningen - det gjør det interne navneproblemet mykt og vil være enklere generelt å vedlikeholde og utvide fremover. Dessverre vil dette alternativet trolig kreve betydelig arbeid foran, men Microsoft Exchange-servere kan settes opp å bruke fullt kvalifiserte offentlige domenenavn (og dette CA / nettleserforumet hvitt papir forteller mer om implementering av FQDN i Active Directory-nettverk). Administrasjon etter overgangen vil nesten helt sikkert være like enkel eller enklere enn før (et stort pluss for Bob) og fremover vil AwfulBigCo kunne bruke offentlig klarerte sertifikater for å sikre all trafikk både internt og eksternt. En mulig ulempe med denne metoden er at den kan tillate informasjon om selskapets interne infrastruktur å bli oppdaget via DNS, men kunnskapsrik konfigurasjon av DNS-soner kan bidra til å løse dette - for eksempel ved å bruke underdomener som "interne" eller separate domenenavn og begrense oppløsningen. av disse utenfor bedriftsnettverk.
2. Registrer interne navn som FQDN.
   Dessverre er ikke et alternativ for den reserverte IP-adressen, og "Mail" og "Gandalf" selvfølgelig rett ut. (Vi antar for Bobs sunnhet at domenene .com og .co.uk allerede er trygt registrert - dagen hans er tøff nok som den er.)
   Også, selv om abc.utveksling er tilgjengelig - og husk at .exchange er en av de nye toppdomene som har introduksjon som hjelper til med å drive denne regelendringen - det kan godt hukes på den og bare tilgjengelig for en ublu pris - enklere og billigere alternativer er sannsynligvis tilgjengelige.
3. Sett opp en Enterprise CA
   Dette er en metode som allerede er brukt av virkelig store enheter som først og fremst trenger å sikre intern kommunikasjon. En virksomhets-CA fungerer som en myndighetssertifikatmyndighet - i hovedsak er i stedet for tillitskjeden opp til en ekstern CA, alle sertifikater til slutt sikret av et internt generert rotsertifikat. Selv om dette gir større tilpasning (og vil tillate Bob å opprettholde den eldre navngivningsstrukturen AwfulBigCo har på plass) det er alvorlige sikkerhetsproblemer å vurdere - et hack i Sony-stil kan avsløre enterprise-sertifikatet og / eller den private nøkkelen, noe som gir nesten ubegrenset utnyttelse av nettverket. Også sertifikater som er utstedt internt, vil IKKE stole på andre steder - dette er en metode som sikrer intern kommunikasjon, men som ikke kan utvide tilliten utenfor veggene i bedriftens nettverk. Til slutt er det på ingen måte å etablere en bedrifts-CA en løsning over natten, og det kan være mye vanskeligere enn de andre alternativene som er oppført her, og dermed bare levedyktig for veldig store (eller voksende) nettverk.
   
   SSL.com tilbyr gjerne konsulent- og administrasjonstjenester for å hjelpe deg med å forhandle veien til å opprette din egen Enterprise CA - bare send en melding til enterpriseca@ssl.com og en av våre senioradministratorer vil kontakte deg snart.
4. Bruk selvsignerte sertifikater
   Dette alternativet har lignende ulemper som Enterprise CA, men skalerer ikke godt - siden hvert selvsignerte sertifikat ikke har noen tillitskjede utover seg selv, må hvert enkelt sertifikat installeres på hver klient for å unngå feilmeldinger . Ledelse over et bredt nettverk vil også skape en helt ny mengde hodepine for stakkars Bob - noe så enkelt som automatiske nettleseroppdateringer kan forårsake kaos med mindre kontinuerlig årvåkenhet opprettholdes på hver enhet.

Som alltid, kontakt oss på SSL.com hvis du har spørsmål. Husk - et tryggere internett er et bedre internett.