Yksityinen vai julkinen CA: saatat käyttää väärää

Kiireiselle IT-tiimille julkinen varmenneviranomainen (CA) näyttää usein vasaralta, ja jokainen salausvaatimus näyttää naulalta. Julkisen CA:n käyttäminen joka tehtävään on kuitenkin yksi yleisimmistä tavoista rikkoa tuotanto huomaamatta.

Mihin julkiset CA:t on tarkoitettu

Julkinen CA (kuten DigiCert, Sectigo tai Let's Encrypt) on suunniteltu yhteen päätilanteeseen: kun luottamus pitää saada aikaan laitteiden kanssa, joita et hallitse. Ajatuksena on, ettei ulkoisten käyttäjien tarvitse määrittää omassa päässään mitään luottaakseen sivustoosi tai palveluusi.

Julkinen CA on perusteltu, kun

• pyörität julkisia palveluja ulkoisille käyttäjille, asiakkaille tai kumppaneille, joilla ei ole ennestään luottamussuhdetta organisaatioosi
• ulkoiset rajapinnat tai palvelut ottavat yhteyden infrastruktuuriisi ilman erillisiä asiakasmäärityksiä
• varmennevirheet näkyisivät loppukäyttäjille selaimen varoituksena
• allekirjoitat sähköposteja ja vastaanottajien on voitava tarkistaa allekirjoitus ilman ennakkomäärityksiä.

CA/Browser Forum päättää, mitä julkiset CA:t saavat myöntää. Olet siis sellaisten sääntöjen alainen, joita et hallitse, mikä on monille kohtuullinen vaihtokauppa yllä kuvatuissa tilanteissa. Julkisesta CA:sta voi tulla ongelma, kun käytät samoja varmenteita sisäiseen todennukseen.

Mihin yksityiset CA:t on tarkoitettu

Yksityinen CA on sellainen, jota ylläpidät itse tai jota toimittajasi ylläpitää puolestasi. Sinä määrität myöntämiskäytännön. Varmenteisiin ei oletuksena luoteta missään. Jaat yksityisen CA:si juurivarmenteen laitteillesi ja käyttäjillesi ryhmäkäytännön, Intunen tai MDM-alustasi kautta, ja hallitut päätelaitteesi luottavat yksityisen CA:si myöntämiin varmenteisiin.

Yksityinen CA on oikea valinta kaikkeen, missä varmenteeseen tarvitsee luottaa vain oman infrastruktuurisi:

• Laitetodennus, jolla osoitetaan, että kone on hallittu ja kuuluu organisaatiollesi
• Käyttäjävarmenteilla todennus, salasanaton kirjautuminen, älykorttien korvaajat tai sisäisten sovellusten käyttö
• Wi-Fi-yhteyksien (802.1X) ja VPN-yhteyksien suojaaminen
• Molemminpuolisen TLS:n (mTLS) pystyttäminen taustapalvelujen mikropalvelujen välille
• Sisäisten työkalujen ja skriptien koodin allekirjoitus

Säilytät täyden hallinnan luottamusketjuun ja myöntämiskäytäntöön, etkä ole riippuvainen ulkoisesta CA-hallinnosta.

Julkinen CA vai yksityinen CA? Lyhyt vertailu

Missä asiat menevät pieleen

Yleisin virhe, jonka IT-tiimit tekevät, on julkisen CA:n varmenteiden käyttö sisäiseen todennukseen. Julkisia CA:ita ei ole koskaan tarkoitettu sisäisiin kuormiin, ja kaksi parhaillaan käynnissä olevaa muutosta tekevät tästä aukosta mahdottoman sivuuttaa.

1. Julkisissa TLS-varmenteissa ei enää ole Client Authentication -EKU:ta

Julkisesti luotetuissa TLS-varmenteissa ei enää saa olla Client Authentication -EKU:ta. CA/Browser Forumin äänestyksen SC-081 ja suurten juuriohjelmien päivitysten vauhdittamina julkiset CA:t luopuvat clientAuthista ennen maaliskuun 2027 takarajaa. Jos sisäinen laite- tai käyttäjätodennuksesi nojaa julkisiin varmenteisiin, nuo kokoonpanot lakkaavat toimimasta seuraavassa uusimisessa.

2. Nopeasti lyhenevä voimassaoloaika

Julkiset CA:t lyhentävät varmenteiden voimassaoloaikoja jatkuvasti. SC-081v3:n mukaan julkisten varmenteiden voimassaoloraja on 200 päivää (2026), maaliskuussa 2027 se putoaa 100 päivään ja maaliskuuhun 2029 mennessä 47 päivään. Automatisoidut työkalut hoitavat 90 päivän uusimiset julkisilla verkkopalvelimilla hyvin, mutta tuhansien sisäisten kannettavien tai laitteiden uudelleenrekisteröinti kuuden viikon välein on hallinnollinen painajainen.

Yksityinen CA jää näiden rajoitusten ulkopuolelle. Koska hoidat peruutukset suoraan omassa ympäristössäsi, et tarvitse keinotekoisen lyhyitä voimassaoloaikoja etkä ulkoisia tarkistuksia. Sinä asetat ne voimassaoloajat ja säännöt, jotka sopivat tiimillesi.

Kumman valitset

Kysy jokaisesta ympäristösi varmenteesta: hallitsetko jokaista laitetta tai asiakasta, jonka pitää tarkistaa tämä varmenne?

• Jos kyllä: Käytä yksityistä CA:ta. Jaat juuri-CA:n varmenteen, hallitset sitä mitä myönnetään ja vapaudut ulkoisista sääntömuutoksista.
• Jos ei: Tarvitset julkisen CA:n. Ulkopuolelta ilman ennakkomäärityksiä yhteyttä ottava tarvitsee CA:n, johon hänen laitteensa jo luottaa.

Useimmat IT-osastot päätyvät tarvitsemaan molempia: julkisia varmenteita ulospäin näkyviin palveluihin ja yksityisiä varmenteita laitteille, käyttäjille ja sisäisille palveluille.

Miten SCEPman sopii kuvaan

SCEPman on pilvinatiivi yksityinen CA, joka integroituu Microsoft Intuneen ja Entra ID:hen sekä muihin MDM-alustoihin SCEPin ja EST:n kautta. Se hoitaa varmenteiden automaattisen myöntämisen hallituille laitteille ja käyttäjille.

Intune-ympäristöissä SCEPman sitoo varmenteen voimassaolon laitteen vaatimustenmukaisuuteen. Laite, joka tyhjennetään tai joka lakkaa täyttämästä vaatimuksia, menettää varmenteensa, jolloin pääsy Wi-Fi-verkkoon, VPN:ään ja sisäisiin sovelluksiin katkeaa automaattisesti.

SCEPman voi myös myöntää varmenteita manuaalisesti Certificate Masterin avulla. Näin IT-osastot voivat korvata julkisen CA:n varmenteet sisäisissä järjestelmissä, kuten verkkoportaaleissa, sovelluksissa ja laitehallinnan käyttöliittymissä.

Mistä aloittaa

Jos sinulla ei ole yksityistä CA:ta tai olet luopumassa vanhasta paikallisesta Active Directory Certificate Servicesistä (ADCS), se on hyvä lähtökohta keskustelulle SCEPmanista.

Kokeile SCEPmania itse

Aloita 30 päivän kokeilu ja katso, miten SCEPman myöntää ja hallitsee yksityisen CA:n varmenteita laitteillesi, käyttäjillesi ja sisäisille palveluillesi ilman oman PKI:n pyörittämisen taakkaa.

Aloita SCEPmanin 30 päivän kokeilu

Usein kysytyt kysymykset