[{"data":1,"prerenderedAt":1795},["ShallowReactive",2],{"sc:header-data-fi":3,"sc:footer-data-fi":101,"glossary-posts-fi":139,"content-fi-list-c077398beed29":1794},{"lang":4,"home":5,"navigation":14,"contact":95},"en",{"name":6,"imgLight":7,"img":8,"languages":9},"home","/products/scepman/scepman-logo-all-white.svg","/products/scepman/scepman-logo-rgb.svg",{"fi":10},{"title":11,"url":12,"alt":13},"Etusivu","/fi","SCEPman",[15,19,25,31,83,89],{"name":16,"languages":17},"nav-home",{"fi":18},{"title":11,"url":12},{"name":20,"languages":21},"pricing",{"fi":22},{"title":23,"url":24},"Hinnat","/fi/pricing",{"name":26,"languages":27},"partner",{"fi":28},{"title":29,"url":30},"Kumppanit","/fi/partner",{"name":32,"languages":33,"children":36},"support-hub",{"fi":34},{"title":35},"Support Hub",[37,53,68],{"name":38,"children":39},"support-hub-group-1",[40,47],{"name":41,"target":42,"languages":43},"docs","_blank",{"fi":44},{"title":45,"url":46},"Docs","https://docs.scepman.com/",{"name":48,"languages":49},"faq",{"fi":50},{"title":51,"url":52},"FAQ","/fi/faq",{"name":54,"children":55},"support-hub-group-2",[56,62],{"name":57,"target":42,"languages":58},"support-ticket",{"fi":59},{"title":60,"url":61},"Support Ticket","https://support.scepman.com/support/tickets/new?ticket_form=technical_support_request_%28scepman%29",{"name":63,"target":42,"languages":64},"drop-a-question",{"fi":65},{"title":66,"url":67},"Drop a Question","https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29",{"name":69,"children":70},"support-hub-group-3",[71,77],{"name":72,"languages":73},"glossary",{"fi":74},{"title":75,"url":76},"Sanasto","/fi/glossary",{"name":78,"languages":79},"blog",{"fi":80},{"title":81,"url":82},"Blogi","/fi/blog",{"name":84,"languages":85},"events",{"fi":86},{"title":87,"url":88},"Tapahtumat","/fi/events",{"name":90,"languages":91},"about",{"fi":92},{"title":93,"url":94},"Tietoa meistä","/fi/about-us",{"name":96,"languages":97},"contact",{"fi":98},{"title":99,"url":100},"support@scepman.com","mailto:support@scepman.com",{"data":102},{"mail":103,"logos":104,"socials":109,"links":122,"linksFi":132},"sales@SCEPman.com",[105],{"img":106,"alt":107,"url":108},"/products/scepman/scepman-logo-yellow.svg","SCEPman Logo","/",[110,114,118],{"icon":111,"url":112,"title":113},"fa-x-twitter","https://twitter.com/scepman_","X",{"icon":115,"url":116,"title":117},"fa-youtube","https://www.youtube.com/channel/UCKnLYxlQFhzdXkDADV_Unrg","Youtube",{"icon":119,"url":120,"title":121},"fa-linkedin","https://www.linkedin.com/showcase/scepman","LinkedIn",[123,126,129],{"title":124,"url":125,"target":42},"Privacy","https://www.glueckkanja.com/en/privacy",{"title":127,"url":128,"target":42},"Imprint","https://www.glueckkanja.com/en/imprint",{"title":130,"url":131,"target":42},"Contact & Locations","https://www.glueckkanja.com/en/company/contact-and-locations",[133,135,137],{"title":134,"url":125,"target":42},"Tietosuoja",{"title":136,"url":128,"target":42},"Oikeudelliset tiedot",{"title":138,"url":131,"target":42},"Yhteystiedot ja toimipaikat",[140,478,849,1107,1343],{"id":141,"title":142,"author":143,"body":144,"cta":143,"description":435,"eventid":143,"extension":458,"hideInRecent":459,"layout":460,"meta":461,"moment":143,"navigation":473,"path":474,"seo":475,"stem":476,"tags":143,"webcast":459,"__hash__":477},"content_fi/glossary/cryptography.md","Kryptografia",null,{"type":145,"value":146,"toc":434},"minimal",[147,152,164,171,199,205,227,231,234,237,246,249,257,296,300,303,307,310,314,317,321,324,327,331,335,338,364,368,371,388,392,395,399,402,406,409,414],[148,149,151],"h2",{"id":150},"mitkä-ovat-kaksi-avainpohjaisen-salauksen-päätyyppiä","Mitkä ovat kaksi avainpohjaisen salauksen päätyyppiä?",[153,154,155,156,160,161],"p",{},"Avainpohjaisen salauksen kaksi päätyyppiä ovat ",[157,158,159],"strong",{},"symmetrinen salaus"," ja ",[157,162,163],{},"epäsymmetrinen salaus.",[165,166,168],"h3",{"id":167},"symmetrinen-salaus",[157,169,170],{},"Symmetrinen salaus",[172,173,174,181,187,193],"ul",{},[175,176,177,180],"li",{},[157,178,179],{},"Avainten käyttö",": Käyttää samaa avainta sekä salaukseen että purkamiseen.",[175,182,183,186],{},[157,184,185],{},"Nopeus",": Yleisesti ottaen nopeampi ja tehokkaampi.",[175,188,189,192],{},[157,190,191],{},"Tietoturva",": Suurin haaste on avaimen turvallinen jakaminen osapuolten kesken.",[175,194,195,198],{},[157,196,197],{},"Esimerkkejä",": AES (Advanced Encryption Standard), DES (Data Encryption Standard).",[165,200,202],{"id":201},"epäsymmetrinen-salaus",[157,203,204],{},"Epäsymmetrinen salaus",[172,206,207,212,217,222],{},[175,208,209,211],{},[157,210,179],{},": Käyttää avainparia, jossa julkisella avaimella salataan ja yksityisellä avaimella puretaan.",[175,213,214,216],{},[157,215,185],{},": Symmetristä salausta hitaampi, koska laskenta on monimutkaisempaa.",[175,218,219,221],{},[157,220,191],{},": Turvallisempi avainten jakelussa, koska yksityistä avainta ei koskaan jaeta.",[175,223,224,226],{},[157,225,197],{},": RSA (Rivest-Shamir-Adleman), ECC (Elliptic Curve Cryptography).",[165,228,230],{"id":229},"kumpaa-salaustyyppiä-pidetään-turvallisempana","Kumpaa salaustyyppiä pidetään turvallisempana?",[153,232,233],{},"Molempia pidetään turvallisina siinä mielessä, että jos käytät nykyaikaista algoritmia ja riittävän pitkää avainta, mikään nykyinen tietokone ei pysty murtamaan salausta.",[153,235,236],{},"Kumpi salaustyyppi on parempi, riippuu käyttötapauksesta, mutta moni käyttötapaus edellyttää epäsymmetristä salausta, koska siinä käytetään avainparia: julkisella avaimella salataan ja yksityisellä avaimella puretaan. Yksityinen avain pidetään salassa, mikä parantaa tietoturvaa, koska sitä ei tarvitse koskaan jakaa.",[165,238,240,241],{"id":239},"kumpi-salaustyyppi-soveltuu-paremmin-suurille-tietomäärille","Kumpi salaustyyppi soveltuu paremmin suurille tietomäärille? ",[242,243],"a",{"href":244,"id":245},"#which-type-of-encryption-is-better-for-bulk-data","which-type-of-encryption-is-better-for-bulk-data",[153,247,248],{},"Symmetrinen salaus, koska se on nopeampaa.",[165,250,252,253],{"id":251},"miten-hybridisalaus-etenee-yleisellä-tasolla","Miten hybridisalaus etenee yleisellä tasolla? ",[242,254],{"href":255,"id":256},"#what-is-the-general-process-for-hybrid-encryption","what-is-the-general-process-for-hybrid-encryption",[258,259,260,266,272,278,284,290],"ol",{},[175,261,262,265],{},[157,263,264],{},"Avaimen luonti",": Lähettäjä luo uuden symmetrisen avaimen (jota kutsutaan myös istuntoavaimeksi) varsinaisen viestin salaamista varten.",[175,267,268,271],{},[157,269,270],{},"Viestin salaus",": Lähettäjä salaa selkokielisen viestin symmetrisellä avaimella, jolloin syntyy salateksti.",[175,273,274,277],{},[157,275,276],{},"Avaimen salaus",": Tämän jälkeen lähettäjä salaa symmetrisen avaimen vastaanottajan julkisella avaimella (epäsymmetrinen salaus).",[175,279,280,283],{},[157,281,282],{},"Lähetys",": Lähettäjä lähettää vastaanottajalle sekä salatun viestin (salatekstin) että salatun symmetrisen avaimen.",[175,285,286,289],{},[157,287,288],{},"Avaimen purku",": Vastaanottaja purkaa symmetrisen avaimen omalla yksityisellä avaimellaan.",[175,291,292,295],{},[157,293,294],{},"Viestin purku",": Lopuksi vastaanottaja purkaa salatekstin puretulla symmetrisellä avaimella ja saa alkuperäisen selkokielisen viestin.",[148,297,299],{"id":298},"tiivistealgoritmit","Tiivistealgoritmit",[153,301,302],{},"Tiivistealgoritmi on matemaattinen funktio, joka muuntaa minkä tahansa kokoisen syötteen kiinteämittaiseksi merkkijonoksi, tyypillisesti kirjainten ja numeroiden jonoksi. Tätä tulosta kutsutaan tiivistearvoksi eli digestiksi.",[165,304,306],{"id":305},"mikä-on-törmäys","Mikä on törmäys?",[153,308,309],{},"Tiivistyksessä törmäys tapahtuu, kun kaksi erilaista tietojoukkoa tuottaa tiivistealgoritmilla saman tiivistearvon. Tämä on ongelmallista, koska tiivistealgoritmin ensisijainen tarkoitus on esittää erilaiset syötteet yksikäsitteisesti.",[165,311,313],{"id":312},"mikä-on-mac","Mikä on MAC?",[153,315,316],{},"Message Authentication Code (MAC): Kryptografiassa MAC on lyhyt tieto, jolla viesti todennetaan ja sen eheys varmistetaan. Se osoittaa, ettei viestiä ole muutettu, ja vahvistaa lähettäjän identiteetin.",[165,318,320],{"id":319},"miten-mac-eroaa-hmacsta","Miten MAC eroaa HMAC:sta?",[153,322,323],{},"MAC: Yleisnimitys koodille, joka varmistaa viestin eheyden ja aitouden joko lohkosalaimilla tai tiivistefunktioilla.",[153,325,326],{},"HMAC: Tietty MAC-tyyppi, joka käyttää kryptografista tiivistefunktiota ja salaista avainta ja tarjoaa vahvemmat turvaominaisuudet.",[148,328,330],{"id":329},"epäsymmetrinen-kryptografia","Epäsymmetrinen kryptografia",[165,332,334],{"id":333},"miten-viestin-allekirjoitus-etenee-yleisellä-tasolla","Miten viestin allekirjoitus etenee yleisellä tasolla?",[153,336,337],{},"Viestin allekirjoitus on kryptografinen prosessi, jolla varmistetaan viestin aitous ja eheys.",[258,339,340,346,352,358],{},[175,341,342,345],{},[157,343,344],{},"Tiivisteen luonti:"," Lähettäjä luo viestistä yksilöllisen digitaalisen sormenjäljen (tiivisteen) kryptografisella tiivistefunktiolla (esimerkiksi SHA-256). Tämä tiiviste esittää viestin sisällön yksikäsitteisesti.",[175,347,348,351],{},[157,349,350],{},"Allekirjoitus:"," Lähettäjä salaa tiivisteen yksityisellä avaimellaan, jolloin syntyy digitaalinen allekirjoitus. Näin allekirjoituksen voi luoda vain se, jolla on pääsy lähettäjän yksityiseen avaimeen.",[175,353,354,357],{},[157,355,356],{},"Lähetys:"," Digitaalinen allekirjoitus liitetään viestiin, ja molemmat lähetetään vastaanottajalle. Myös lähettäjän julkinen avain toimitetaan todentamista varten.",[175,359,360,363],{},[157,361,362],{},"Todentaminen:"," Vastaanottaja purkaa digitaalisen allekirjoituksen lähettäjän julkisella avaimella ja saa alkuperäisen tiivisteen. Tämän jälkeen vastaanottaja luo vastaanotetusta viestistä uuden tiivisteen ja vertaa sitä puretun allekirjoituksen tiivisteeseen. Jos ne täsmäävät, viestiä ei ole muutettu ja lähettäjän identiteetti on vahvistettu.",[165,365,367],{"id":366},"mitkä-ovat-epäsymmetrisen-salauksen-kolme-tehtävää","Mitkä ovat epäsymmetrisen salauksen kolme tehtävää?",[153,369,370],{},"Epäsymmetrisellä salauksella, jota kutsutaan myös julkisen avaimen kryptografiaksi, on useita tärkeitä tehtäviä viestinnän ja tiedon suojaamisessa.",[258,372,373,378,383],{},[175,374,375],{},[157,376,377],{},"Salaus ja purku",[175,379,380],{},[157,381,382],{},"Digitaaliset allekirjoitukset",[175,384,385],{},[157,386,387],{},"Avaintenvaihto",[165,389,391],{"id":390},"rsa","RSA",[153,393,394],{},"RSA, lyhenne sanoista Rivest-Shamir-Adleman, on laajalti käytetty julkisen avaimen salausjärjestelmä turvalliseen tiedonsiirtoon. Se on nimetty keksijöidensä Ronald Rivestin, Adi Shamirin ja Leonard Adlemanin mukaan, jotka esittelivät sen vuonna 1977.",[165,396,398],{"id":397},"diffie-hellman","Diffie-Hellman",[153,400,401],{},"Diffie-Hellman-avaintenvaihto on kryptografiassa käytetty menetelmä, jolla salausavaimia vaihdetaan turvallisesti julkisen kanavan kautta. Sen kehittivät Whitfield Diffie ja Martin Hellman vuonna 1976. Diffie-Hellman-avaintenvaihdon päätarkoitus on antaa kahdelle osapuolelle mahdollisuus muodostaa turvallisesti yhteinen salainen avain, jota voidaan käyttää myöhemmän viestinnän salaamiseen.",[165,403,405],{"id":404},"digital-signature-algorithm-dsa","Digital Signature Algorithm (DSA)",[153,407,408],{},"Digital Signature Algorithm (DSA) on julkisen avaimen salausalgoritmi, jolla luodaan ja todennetaan digitaalisia allekirjoituksia. National Institute of Standards and Technology (NIST) esitti sen vuonna 1991 osana Digital Signature Standardia (DSS).",[410,411,413],"h4",{"id":412},"miten-se-toimii","Miten se toimii",[258,415,416,422,428],{},[175,417,418,421],{},[157,419,420],{},"Avainten luonti:"," DSA luo avainparin: yksityisen avaimen allekirjoittamiseen ja julkisen avaimen todentamiseen.",[175,423,424,427],{},[157,425,426],{},"Allekirjoitus",": Lähettäjä luo yksityisellä avaimellaan viestiin digitaalisen allekirjoituksen. Allekirjoitus on yksilöllinen sekä viestin että yksityisen avaimen suhteen.",[175,429,430,433],{},[157,431,432],{},"Todentaminen",": Vastaanottaja varmistaa lähettäjän julkisella avaimella allekirjoituksen aitouden ja sitä kautta viestin eheyden ja alkuperän.",{"title":435,"searchDepth":436,"depth":436,"links":437},"",2,[438,446,451],{"id":150,"depth":436,"text":151,"children":439},[440,442,443,444,445],{"id":167,"depth":441,"text":170},3,{"id":201,"depth":441,"text":204},{"id":229,"depth":441,"text":230},{"id":239,"depth":441,"text":240},{"id":251,"depth":441,"text":252},{"id":298,"depth":436,"text":299,"children":447},[448,449,450],{"id":305,"depth":441,"text":306},{"id":312,"depth":441,"text":313},{"id":319,"depth":441,"text":320},{"id":329,"depth":436,"text":330,"children":452},[453,454,455,456,457],{"id":333,"depth":441,"text":334},{"id":366,"depth":441,"text":367},{"id":390,"depth":441,"text":391},{"id":397,"depth":441,"text":398},{"id":404,"depth":441,"text":405},"md",false,"post",{"lang":462,"titleClass":463,"blogtitlepic":464,"socialimg":465,"customExcerpt":466,"asideNav":467,"maxContent":473},"fi","h1-font-size","header-scepman-cryptography.png","/blog/heads/header-scepman-cryptography.png","Varmenteiden rekisteröinnin keskeinen haaste on se, miten varmennetta pyytävä laite tai käyttäjä todennetaan. Varmenteella CA vahvistaa, että varmenteen omistajalla on tietyt ominaisuudet ja että se on tarkistanut niiden aitouden",{"menuItems":468},[469,471],{"href":470,"text":299},"#tiivistealgoritmit",{"href":472,"text":330},"#epäsymmetrinen-kryptografia",true,"/glossary/cryptography",{"title":142,"description":435},"glossary/cryptography","SjWGS3U6sv20r__pIpCLGsz2CYQgBGYosx0FGnj3sNk",{"id":479,"title":480,"author":143,"body":481,"cta":143,"description":485,"eventid":143,"extension":458,"hideInRecent":459,"layout":460,"meta":833,"moment":143,"navigation":473,"path":845,"seo":846,"stem":847,"tags":143,"webcast":459,"__hash__":848},"content_fi/glossary/enrollment-methods.md","Rekisteröintimenetelmät",{"type":145,"value":482,"toc":820},[483,486,489,492,521,611,613,617,627,631,649,652,655,659,662,665,686,690,693,696,709,713,716,719,722,725,728,731,740,743,747,751,754,760,764,773,776,779,782,799,810,813,816],[153,484,485],{},"Siksi varmenteiden rekisteröintiprotokollien yksi keskeinen ominaisuus on se, miten ne todentavat varmennetta pyytävän osapuolen. Sen mukaan, mihin varmennetta käytetään, yksi tai toinen protokolla on edullisempi.",[153,487,488],{},"Toinen tärkeä ominaisuus on protokollan käytännön yleisyys. Rekisteröintimenetelmää tai -protokollaa on tuettava aiotussa käyttötapauksessa sekä CA:n että asiakaspään puolella.",[153,490,491],{},"Suosituimmat rekisteröintiprotokollat ovat:",[172,493,494,500,503,506,512,515,518],{},[175,495,496],{},[242,497,499],{"href":498},"scep","SCEP",[175,501,502],{},"ACME",[175,504,505],{},"EST",[175,507,508],{},[242,509,511],{"href":510},"microsoft-rpc-dcom","Microsoftin RPC/DCOM",[175,513,514],{},"Microsoftin SOAP",[175,516,517],{},"Manuaalinen rekisteröinti CA:n verkkosivulla",[175,519,520],{},"Muut valmistajakohtaiset protokollat",[522,523,524,525],"table",{},"\n    ",[526,527,528,524,550,531,571,524,591],"tbody",{},[529,530,531,532,531,535,531,538,531,541,531,544,531,547,524],"tr",{},"\n        ",[533,534],"th",{},[533,536,537],{},"Microsoftin oma DCOM ja RPC",[533,539,540],{},"WS-Trust Enrollment Extension SOAP Enrollment",[533,542,543],{},"Automatic Certificate Management Environment (ACME)",[533,545,546],{},"Simple Certificate Enrollment Protocol (SCEP)",[533,548,549],{},"Enrollment over Secure Transport (EST)",[529,551,531,552,531,556,531,559,531,562,531,565,531,568,524],{},[553,554,555],"td",{},"Määrittelyt",[553,557,558],{},"Microsoft OpenSpec1",[553,560,561],{},"Microsoft OpenSpec2",[553,563,564],{},"RFC 8555",[553,566,567],{},"Epävirallinen, nykyisin RFC 8894",[553,569,570],{},"RFC 7030 (+ …)",[529,572,531,573,531,576,531,579,531,582,531,585,531,588,524],{},[553,574,575],{},"Toteutus",[553,577,578],{},"Palvelinpuoli: Active Directory CS Asiakaspuoli: Windows",[553,580,581],{},"Palvelinpuoli: ADCS, muita? Asiakaspuoli: Windows",[553,583,584],{},"Palvelinpuoli: Let’s Encrypt Asiakaspuoli: monia",[553,586,587],{},"Useita palvelin- ja asiakastoteutuksia",[553,589,590],{},"Vähäinen käyttöönotto",[529,592,531,593,531,596,531,599,531,602,531,605,531,608,524],{},[553,594,595],{},"Todennus",[553,597,598],{},"AD-todennus",[553,600,601],{},"AD-todennus\\* (tarkkaan ottaen käyttäjätunnus ja salasana eivät välttämättä ole AD:ssa)",[553,603,604],{},"DNS-todennus",[553,606,607],{},"”SCEP Challenge”",[553,609,610],{},"CBA tai HTTP Basic/Digest -todennus",[148,612,499],{"id":498},[165,614,616],{"id":615},"historia-ja-määrittely","Historia ja määrittely",[153,618,619,620,626],{},"Cisco kehitti alun perin Simple Certificate Enrollment Protocolin (SCEP). Vaikka standardia ei tuolloin ollut, protokolla yleistyi laajasti MDM-järjestelmissä. Cisco jatkoi vielä eteenpäin ja suunnitteli seuraajaprotokollan, Enrollment over Secure Transportin (EST), korvaamaan SCEPin. Siksi EST:stä tuli julkinen standardi RFC 7030:ssa paljon aiemmin kuin SCEPistä, joka standardoitiin ",[242,621,625],{"href":622,"rel":623},"https://www.rfc-editor.org/rfc/rfc8894.html",[624],"nofollow","RFC 8894:ssä"," huomattavasti myöhemmin, kun se oli jo vakiintunut MDM-järjestelmien varmennerekisteröinnin tosiasialliseksi standardiksi.",[165,628,630],{"id":629},"tekniikka","Tekniikka",[153,632,633,634,638,639,643,644,648],{},"SCEP perustuu HTTP:hen. SCEP-pyyntö on salattu ja allekirjoitettu ",[242,635,637],{"href":636},"important-data-formats#pkcs7","PKCS#7",", joka lähetetään SCEP-palveluun GET- tai POST-pyynnöllä. Palvelu vastaa SCEP-vastauksella, joka on jälleen salattu ja allekirjoitettu PKCS#7. Pyyntö sisältää ",[242,640,642],{"href":641},"important-data-formats#pkcs10","PKCS#10"," -varmennepyynnön, ja vastaus sisältää myönnetyn ",[242,645,647],{"href":646},"important-data-formats#x509","X.509-varmenteen",".",[165,650,595],{"id":651},"todennus",[153,653,654],{},"PKCS#10-pyyntö sisältää ”SCEP Challenge” -arvon, joka todentaa ja valtuuttaa allekirjoituspyynnön jollakin varsinaisen kanavan ulkopuolisella menetelmällä kulloisenkin SCEP-palvelun mukaan. Käytännössä käytössä on nykyään kolmenlaisia SCEP Challenge -arvoja:",[410,656,658],{"id":657},"staattinen-scep-challenge","Staattinen SCEP Challenge",[153,660,661],{},"Yksinkertaisin vaihtoehto on staattinen tunnuslause. Jos PKCS#10-pyynnön SCEP Challenge vastaa SCEP-palveluun tallennettua ennalta määritettyä arvoa, varmenne myönnetään, muussa tapauksessa pyyntö hylätään. Menetelmän ongelma on se, että käytännössä ei voida mitenkään tarkistaa, vastaavatko varmenteelle pyydetyt ominaisuudet pyytäjää. Tästä ongelmasta on olemassa jopa oma CVE.",[153,663,664],{},"Näitä menetelmiä voidaan eritellä tarkemmin:",[258,666,667,674,680],{},[175,668,669,673],{},[670,671,672],"em",{},"Suorassa"," SCEP-rekisteröinnissä se taho, jolle varmenne on tarkoitus myöntää, viestii suoraan SCEP-palvelun kanssa. Esimerkiksi MDM-järjestelmä kehottaa jotakin Android-puhelinta tekemään SCEP-rekisteröinnin SCEP Challenge -arvolla ”SecurePassword”. Android-puhelin luo CSR:n, toivottavasti oikeilla arvoilla, ja lisää ”SecurePassword”-arvon SCEP Challengeksi. Sen jälkeen se lähettää CSR:n SCEP-palveluun ja saa vastauksena myönnetyn varmenteen.",[175,675,676,679],{},[670,677,678],{},"Läpinäkyvä SCEP-välityspalvelin"," toimii aivan kuten HTTP:n käänteinen välityspalvelin. Koska SCEP on salattu ja allekirjoitettu, se ei tosiasiassa pysty katsomaan SCEP-pyyntöjen tai -vastausten sisään eikä muuttamaan niitä, mutta se voi ohjata verkkorajojen perusteella, kuka voi rekisteröidä varmenteita ja milloin.",[175,681,682,685],{},[670,683,684],{},"Protokollasovittimena toimiva SCEP-välityspalvelin"," on järjestelmä, joka pyytää varmenteita SCEPin kautta jonkin toisen järjestelmän puolesta. Esimerkiksi JAMFin kaltainen MDM-järjestelmä voisi pyytää varmennetta SCEP-palvelusta jonkin iPhonen puolesta. Kun sillä on varmenne ja yksityinen avain, se voi jaella varmenteen jotakin toista protokollaa käyttäen. Näin vain MDM-järjestelmällä on pääsy SCEP Challenge -arvoon, ja se voi lisäksi hallita varmenteen sisältöä.",[410,687,689],{"id":688},"dynaaminen-scep-challenge","Dynaaminen SCEP Challenge",[153,691,692],{},"Tällöin kukin SCEP Challenge on voimassa vain yhtä varmennepyyntöä varten. Näin SCEP-palvelu voi tunnistaa SCEP-pyynnön ja varmistaa, että varmenteelle pyydetyt ominaisuudet vastaavat kyseiselle pyynnölle sallittuja.",[153,694,695],{},"Käytännössä on yleensä kaksi tapaa, joilla MDM-järjestelmä ja SCEP-CA voivat sopia pyynnössä käytettävästä SCEP Challenge -arvosta:",[258,697,698,706],{},[175,699,700,701],{},"MDM-järjestelmä pyytää SCEP-palvelulta kertakoodin SCEP-pyyntöä varten, jos se tarvitsee sellaisen.\n",[258,702,703],{},[175,704,705],{},"Esimerkkinä on Microsoft NDES. NDESissä on erillinen hallintasivu, joka todennetaan AD-tunnuksilla. Jokaisella hallintasivun avauskerralla se luo ja näyttää uuden kertakoodin, jota voi käyttää yhteen SCEP-pyyntöön. Tässä kokoonpanossa NDES ei kuitenkaan tarkista varmenteen ominaisuuksia lainkaan, koska kertakoodi on yleinen.",[175,707,708],{},"MDM-järjestelmä luo kertakoodin silloin, kun se kehottaa hallittua järjestelmää pyytämään varmennetta SCEPin kautta. Kun SCEP-pyyntö saapuu SCEP-palveluun, palvelun on haettava kertakoodi MDM-järjestelmästä, yleensä web-koukun avulla, ja tarkistettava, vastaako se pyynnön SCEP Challenge -arvoa. Tälle protokollalle ei ole standardia, joten MDM-järjestelmän ja SCEP-palvelun on sovittava jostakin muodosta, ja toteutuksesta riippuu, tarkistetaanko pyynnön ominaisuuksia lainkaan.",[410,710,712],{"id":711},"allekirjoitettu-metatieto","Allekirjoitettu metatieto",[153,714,715],{},"SCEP Challenge -arvon pituutta ei käytännössä ole rajoitettu. Sen ei siis tarvitse olla ihmisen ymmärrettävissä oleva ”tunnuslause”, vaan se voi olla myös BLOB.",[153,717,718],{},"Intune käyttää SCEP Challenge -arvona allekirjoitettua ja salattua XML:ää. Se luo tämän XML:n palvelinpuolella ja lähettää sen asiakaslaitteelle, kun se haluaa rekisteröidä varmenteen ja luo SCEP-pyynnön.",[153,720,721],{},"SCEP-palvelun on lähetettävä koko PKCS#10-pyyntö Intunen SCEP Challenge -palveluun. SCEP Challenge -palvelulla on yksityinen avain XML:n purkamiseen ja julkinen avain sen tarkistamiseen, että sen on luonut aito Intune-palvelu.",[153,723,724],{},"XML sisältää pyyntöä koskevaa metatietoa, esimerkiksi sen, millainen Subject-kentän pitäisi olla. Tämä johdetaan toisaalta SCEP-määritysprofiilista ja toisaalta sen käyttäjän tai laitteen objektitiedoista, jolle varmenne on tarkoitus myöntää.",[153,726,727],{},"Esimerkiksi SCEP-määritysprofiilissa voi olla Subject-kentäksi määritetty CN={{DeviceId}}. Kun laite, jonka tunnus on xyz, pyytää varmennetta, XML kertoo, että Subject-kentän pitäisi olla CN=xyz. SCEP Challenge -palvelu vertaa sitten XML:n tietoja PKCS#10-pyynnön Subject-kenttään. Tarkistus epäonnistuu, jos Subject-kentät eroavat, ja onnistuu, jos tämä ja muut ominaisuudet täsmäävät.",[153,729,730],{},"SCEP-palvelu myöntää varmenteen vain, jos tarkistus onnistuu.",[153,732,733,734,739],{},"Microsoftilla on ",[242,735,738],{"href":736,"rel":737},"https://learn.microsoft.com/en-us/mem/intune/protect/certificate-authority-add-scep-overview#overview",[624],"artikkeli",", jossa tämä tarkistus selitetään.",[153,741,742],{},"Microsoft NDES tukee tätä erillisen NDES Policy Modulen avulla, muut SCEP-CA:t voivat tukea sitä natiivisti tai olla tukematta.",[148,744,746],{"id":745},"microsoft-rpcdcom","Microsoft RPC/DCOM",[165,748,750],{"id":749},"historia","Historia",[153,752,753],{},"Microsoft Active Directory Certificate Services (ADCS), jota kutsutaan joskus pelkäksi ”Microsoft CA:ksi”, on Windows Serveriin sisäänrakennettu varmenneviranomaisohjelmisto. Ohjelmisto kehitettiin alun perin edellisen vuosituhannen lopulla, ja siihen tehtiin lisäyksiä seuraavien kymmenen tai viidentoista vuoden ajan.",[153,755,756,757,759],{},"Vaihtoehtoja ovat Microsoftin SOAP tai ",[242,758,499],{"href":498},", joita Microsoft kutsuu nimillä Web Enrollment ja NDES.",[165,761,763],{"id":762},"määrittely-ja-käyttöönotto","Määrittely ja käyttöönotto",[153,765,766,767,772],{},"Meillä ei ole tiedossa muita CA-järjestelmiä, jotka toteuttaisivat tämän protokollan, vaikka Microsoft on sittemmin julkaissut ",[242,768,771],{"href":769,"rel":770},"https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cersod/dd034cb3-99fc-4c10-92c8-1fbeb4788183",[624],"määrittelyn Microsoft OpenSpecissä",". Asiakaspäässä Windowsissa on sisäänrakennettu tuki protokollalle, muita alustoja ei tueta.",[165,774,630],{"id":775},"tekniikka-1",[153,777,778],{},"Sen pääasiallinen rekisteröintimenetelmä on RPC:hen tai DCOMiin perustuva valmistajakohtainen protokolla.",[153,780,781],{},"Myös automaattinen rekisteröinti käyttää tätä protokollaa. Jotta automaattinen rekisteröinti toimisi, tarvitset",[172,783,784,787,790,793,796],{},[175,785,786],{},"toimialueeseen liitetyn laitteen.",[175,788,789],{},"Ryhmäkäytäntö ottaa automaattisen rekisteröinnin käyttöön,",[175,791,792],{},"Enterprise CA:n (erotuksena erillisestä CA:sta),",[175,794,795],{},"joka rekisteröi varmennemallin, johon",[175,797,798],{},"käyttäjällä tai laitteella on rekisteröinti- ja automaattisen rekisteröinnin oikeudet.",[153,800,801,802,806,807,648],{},"Automaattisten rekisteröintien oletustarkistusväli on 8 tuntia, joskin sen voi pakottaa komennolla ",[803,804,805],"code",{},"certutil -pulse"," tai usein paremmin komennolla ",[803,808,809],{},"gpupdate -force",[165,811,595],{"id":812},"todennus-1",[153,814,815],{},"Tämä protokolla käyttää Active Directoryyn sisäänrakennettuja todennusprotokollia, eli käyttäjät ja tietokoneet todentautuvat AD-tunnuksillaan.",[817,818,819],"style",{},"\n    table {border: 2px solid white}\n    th, td {border: solid black; padding-left: 1em; padding-right: 1em; font-size: smaller}\n",{"title":435,"searchDepth":436,"depth":436,"links":821},[822,827],{"id":498,"depth":436,"text":499,"children":823},[824,825,826],{"id":615,"depth":441,"text":616},{"id":629,"depth":441,"text":630},{"id":651,"depth":441,"text":595},{"id":745,"depth":436,"text":746,"children":828},[829,830,831,832],{"id":749,"depth":441,"text":750},{"id":762,"depth":441,"text":763},{"id":775,"depth":441,"text":630},{"id":812,"depth":441,"text":595},{"lang":462,"seoTitle":834,"titleClass":463,"socialimg":835,"blogtitlepic":836,"customExcerpt":837,"keywords":838,"asideNav":839,"maxContent":473},"Varmenteiden rekisteröintimenetelmät - SCEP, ACME, EST ja Microsoft RPC","/blog/heads/header-scepman-enrollment-methods.png","header-scepman-enrollment-methods.png","Lue, miten varmenteiden rekisteröinti toimii SCEP-, ACME-, EST- ja Microsoft RPC -protokollilla sekä manuaalisilla menetelmillä. Vertaa PKI:n rekisteröintiprotokollia varmenteiden turvallista myöntämistä varten.","varmenteiden rekisteröintimenetelmät, SCEP, ACME, EST, Microsoft RPC, varmenteiden rekisteröintiprotokolla, varmenteiden rekisteröinti PKI:ssä, enrollment over secure transport, Simple Certificate Enrollment Protocol, Automatic Certificate Management Environment, Microsoft-varmenteiden rekisteröinti",{"menuItems":840},[841,843],{"href":842,"text":499},"#scep",{"href":844,"text":746},"#microsoft-rpcdcom","/glossary/enrollment-methods",{"title":480,"description":485},"glossary/enrollment-methods","Op2S3m02rmlkAkW9UXfohAmyKFLqz3m2ZovEOjJnL6U",{"id":850,"title":851,"author":143,"body":852,"cta":143,"description":435,"eventid":143,"extension":458,"hideInRecent":459,"layout":460,"meta":1085,"moment":143,"navigation":473,"path":1103,"seo":1104,"stem":1105,"tags":143,"webcast":459,"__hash__":1106},"content_fi/glossary/important-data-formats.md","Tärkeät tietomuodot",{"type":145,"value":853,"toc":1068},[854,858,877,884,887,891,895,898,901,904,908,911,915,918,921,929,932,936,943,946,949,952,963,967,980,984,987,990,993,996,1004,1008,1011,1014,1017,1028,1032,1035,1039,1047,1050,1059,1062],[148,855,857],{"id":856},"x509","X.509",[153,859,860,861,864,865,870,871,876],{},"X.509 on ",[670,862,863],{},"se"," digitaalisten varmenteiden standardi. Ennen sillä oli kilpailijoita, kuten ",[242,866,869],{"href":867,"rel":868},"https://www.rfc-editor.org/rfc/rfc4880",[624],"OpenPGP",", mutta niitä käytetään nykyään paljon harvemmin. Mutta hetkinen ... X.509 ei itse asiassa ole oikea standardi. X.509 on tarkkaan ottaen ITU-T:n standardi, kun taas todella merkitykselliset määritelmät ovat osa standardia ",[242,872,875],{"href":873,"rel":874},"https://www.rfc-editor.org/rfc/rfc5280",[624],"RFC 5280",", eli IETF:n eikä ITU-T:n standardia. RFC määrittelee X.509:n pohjalta ”PKI Profile for the Internet” -profiilin, ja se on ainoa profiili, jolla on käytännössä merkitystä.",[153,878,879,880,883],{},"Digitaalinen varmenne hyödyntää epäsymmetristä kryptografiaa ja erityisesti digitaalisia allekirjoituksia. Digitaalisen varmenteen yleisin käyttötapaus on nykyään palvelimen todennus. Kaikki ovat käyttäneet niitä jo, luultavasti enimmäkseen tietämättä, että kyseessä oli X.509-varmenne: aina kun avaat HTTP",[157,881,882],{},"S","-sivuston, selain muodostaa TLS-yhteyden verkkopalvelimeen. Verkkopalvelin todistaa X.509-varmenteella, kuka se on. Kun ihmiset esimerkiksi menevät pankkinsa verkkosivustolle siirtääkseen rahaa tililtään, he haluavat olla varmoja siitä, että he todella viestivät pankkinsa kanssa. Hyökkääjät saattavat yrittää esiintyä pankin sivustona, lukea käyttäjän salasanan ja TAN-koodin ja siirtää sitten rahat hallitsemalleen pankkitilille. HTTPS auttaa estämään tämän, koska hyökkääjillä ei ole pankin verkkopalvelimen X.509-varmennetta. Kun selain kertoo, että olet tietyssä verkkotunnuksessa ja yhteys on HTTPS-yhteys, varmenne takaa, että olet todella yhteydessä verkkopalvelimeen, jonka omistaja hallitsee kyseistä verkkotunnusta.",[153,885,886],{},"Miten varmenne tekee tämän? Varmenne sisältää metatietoa, salausavainparin julkisen avaimen ja varmenneviranomaisen allekirjoituksen. Käydään nämä kolme osaa läpi:",[165,888,890],{"id":889},"x509-varmenteen-sisältö","X.509-varmenteen sisältö",[410,892,894],{"id":893},"metatiedot","Metatiedot",[153,896,897],{},"X.509-varmenteen metatiedot kertovat muun muassa, milloin varmenne on voimassa, mihin sitä on tarkoitus käyttää ja kenelle se on myönnetty. Erityisesti TLS-palvelinvarmenne sisältää verkkopalvelimen verkkotunnuksen. Selain vertaa avaamaansa verkkotunnusta varmenteessa olevaan. Jos ne eivät täsmää, selain ei jatka vaan näyttää varoituksen. Jos varmenne on vanhentunut, selain näyttää myös varoituksen.",[153,899,900],{},"Kummallista kyllä, selaimet eivät usein näyttäneet varoitusta, jos avasit HTTP-sivuston ilman TLS:ää, vaikka se on vieläkin turvattomampaa. Jos avasit verkkopalvelimen, jolla on virheellinen X.509-varmenne, kyseessä voi olla pelkkä virheellinen määritys, ja yhteytesi saattaa silti olla suojassa urkkijoilta, kun taas HTTP-yhteys ei tarjoa mitään suojaa.",[153,902,903],{},"Tässä asiassa on kuitenkin edistytty, esimerkkinä varmenteen kiinnittäminen (Certificate Pinning). Se on kuitenkin edistyneempi aihe, joten katsotaan kahta muuta X.509-varmenteen osaa.",[410,905,907],{"id":906},"julkinen-avain","Julkinen avain",[153,909,910],{},"Varmenne sisältää epäsymmetrisen avainparin julkisen osan. Kryptografia antaa verkkopalvelimelle (tai yleisemmin varmenteen haltijalle, jos käyttötapaus on toinen) mahdollisuuden todistaa, että sillä on hallussaan myös avainparin yksityinen osa, paljastamatta sitä yhteyttä muodostavalle asiakkaalle tai kenellekään muulle. Näin asiakas voi olla varma siitä, että verkkopalvelin todella omistaa varmenteen eikä ole vain joku, joka on kopioinut sen. Itse varmenteen kopiointi on itse asiassa varsin helppoa, koska verkkopalvelin lähettää siitä kopion jokaiselle, joka yrittää muodostaa yhteyden palvelimeen. Yksityisen avaimen varastaminen on vaikeaa tai mahdotonta, koska se ei koskaan poistu verkkopalvelimelta. Yksityisen avaimen varastamista voidaan vaikeuttaa monin keinoin, kuten HSM:illä ja TPM:illä.",[410,912,914],{"id":913},"varmenneviranomaisen-allekirjoitus","Varmenneviranomaisen allekirjoitus",[153,916,917],{},"Metatietojen avulla asiakas voi tarkistaa, että varmenne sopii kyseiseen käyttötapaukseen. Julkinen avain osoittaa, että vastapuoli todella omistaa varmenteen. Mutta hyökkääjä voisi vain luoda uuden avainparin ja uuden varmenteen, joka myös täyttää nämä kaksi ehtoa. Mistä asiakas tietäisi, että varmenne on luotettava?",[153,919,920],{},"Varmenne sisältää kryptografisen allekirjoituksen, joka on tehty toisella avainparilla, joka kuuluu varmenneviranomaisen (CA) varmenteeseen. CA-varmenne voidaan tarkistaa samalla tavalla, ja sekin on allekirjoitettu varmenteella. Asiakas voi seurata tätä ”luottamusketjua” niin sanotusta lehtivarmenteesta Root CA -varmenteeseen asti, jonka se tunnistaa siitä, että se on itse allekirjoitettu, eli varmenteen allekirjoitus on peräisin sen omasta avainparista. Yleensä tämä on vain yksi tai kaksi askelta, joten mukana on vain yksi tai kaksi CA-varmennetta.",[153,922,923,924,928],{},"CA:iden on tarkistettava huolellisesti, että metatiedot ovat oikein, kun ne ",[242,925,927],{"href":926},"enrollment-methods/","myöntävät varmenteen",". Jos esimerkiksi haluat TLS-palvelinvarmenteen omalle verkkotunnuksellesi, sinun on todistettava CA:lle, että todella omistat sen. Sen mukaan, kuinka perusteellinen tämä tarkistus on, saat perusvarmenteen tai Extended Validation (EV) -varmenteen.",[153,930,931],{},"Jokaisen selaimen ja käyttöjärjestelmän mukana tulee luettelo ennalta määritetyistä luotetuista Root CA:ista. Käyttäjät ja järjestelmänvalvojat voivat lisätä muita luotettuja Root CA:ita. Joihinkin Root CA:ihin luotetaan vain tiettyihin tarkoituksiin, toisiin luotetaan yleisemmin. Asiakas tarkistaa, päättyykö luottamusketju luotettuun Root CA:han. Jos päättyy ja kaikki luottamusketjun varmenteet ovat yhä voimassa ja metatiedot kertovat, että niitä käytetään tarkoituksensa mukaisesti, verkkopalvelimen lehtivarmenteeseen luotetaan ja yhteys muodostetaan.",[165,933,935],{"id":934},"x509-varmenteiden-voimassaolo","X.509-varmenteiden voimassaolo",[153,937,938,939,648],{},"X.509-varmenteissa on kyse luottamuksesta, joka on ensin rakennettava. Kuten edellä kerrottiin, yksi luottamuksen ehto on se, että varmenteen ketjun on päädyttävä luotettuun Root CA:han. Toinen on se, että varmenne on voimassaoloaikansa sisällä. Yleensä se tarkoittaa, ettei varmenne ole vanhentunut, mutta varmenne voi myös, tavallisesti teknisten virheiden vuoksi, olla vielä voimaan tulematta. On kuitenkin vielä yksi ehto: varmenteen myöntänyt CA ei saa olla peruuttanut sitä. Koska tämä on oma aiheensa, siitä on ",[242,940,942],{"href":941},"other-stuff/certificate-lifecycle-management","erillinen artikkeli",[148,944,637],{"id":945},"pkcs7",[153,947,948],{},"PKCS#7 on kryptografisten tietomuotojen linkkuveitsi, ja se voi sisältää lähes mitä tahansa: salattuja viestejä, allekirjoitettuja viestejä, allekirjoitettuja ja salattuja viestejä, varmenteita ja yksityisiä avaimia",[153,950,951],{},"Tämä on myös muodon suurin haittapuoli. Kun sovellus tai käyttäjä saa PKCS#7:n, ei ole itsestään selvää, mitä sillä pitäisi tehdä. Tässä muutamia tärkeitä käyttötapauksia:",[172,953,954,957,960],{},[175,955,956],{},"S/MIME-viestit ovat pohjimmiltaan sähköposteja, joiden runko tai liitteet ovat PKCS#7-muotoisia.",[175,958,959],{},"SCEP-pyynnöt ja -vastaukset ovat molemmat itse asiassa allekirjoitettuja PKCS#7-viestejä.",[175,961,962],{},"EST-vastaukset ovat CMS-viestejä.",[165,964,966],{"id":965},"koodaus","Koodaus",[153,968,969,970,974,975,979],{},"Yleisiä tiedostopäätteitä ovat .p7b (",[242,971,973],{"href":972},"asn.1-and-pem#der-encoding","DER-koodattu","), .p7s (allekirjoitettu viesti tai viestin allekirjoitus) ja .p7m (allekirjoitettu ja/tai salattu viesti). Myös ",[242,976,978],{"href":977},"asn.1-and-pem#pem-encoding","PEM-koodaus"," tunnisteella ”PKCS7” on määritelty, mutta sitä käytetään harvoin.",[165,981,983],{"id":982},"työkalut","Työkalut",[153,985,986],{},"Windowsissa voit avata PKCS#7-viestit kaksoisnapsautuksella, jolloin Crypto Shell Extensions näyttää sen sinulle. Yleensä siitä voi kuitenkin poimia vain varmenteita ja niiden yksityisiä avaimia, ei viestien sisältöä.",[153,988,989],{},"Voit muuntaa nämä tiedostot muihin muotoihin OpenSSL:n kaltaisilla työkaluilla.",[148,991,642],{"id":992},"pkcs10",[153,994,995],{},"PKCS#10:ssä määritelty varmennepyyntö (CSR) on tiedosto, joka sisältää kuvauksen varmenteesta, jonka haluaisit hankkia varmenneviranomaiselta (CA). Sen rakenne on samankaltainen kuin X.509-varmenteen, mutta siitä puuttuu CA:n allekirjoitus. Sen sijaan se sisältää varmenteen pyytäjän allekirjoituksen. Kyseessä on silti eri muoto, joten se ei ole sama asia kuin itse allekirjoitettu varmenne.",[153,997,998,999,648],{},"Se voi olla binäärisessä DER-koodauksessa tai PEM-koodattu ",[242,1000,1003],{"href":1001,"rel":1002},"https://datatracker.ietf.org/doc/html/rfc7468#section-7",[624],"käyttäen tunnistetta ”CERTIFICATE REQUEST”",[148,1005,1007],{"id":1006},"pkcs12","PKCS#12",[153,1009,1010],{},"PKCS#12 tunnetaan myös nimellä PFX, erityisesti Windows-ympäristöissä. Yleisiä tiedostopäätteitä ovat siksi .pfx ja .p12. Se sisältää X.509-varmenteita ja lähes aina niitä vastaavat yksityiset avaimet, vaikka sitä ei teknisesti edellytetäkään.",[153,1012,1013],{},"PKCS#12-tiedoston tiedot on yleensä salattu salasanoilla. Usein vain yksityinen avain on salattu, joten voisit poimia varmenteet tietämättä salasanoja, jos sovelluksesi sallii sen (useimmat eivät salli). PKCS#12 on Windows-ympäristöissä yleisin tapa tallentaa varmenne ja sen yksityinen avain tiedostoon. Linux-ympäristöissä yleisempiä ovat PEM-koodatut PKCS#8-tiedostot.",[153,1015,1016],{},"Koska standardi tarjoaa monia vaihtoehtoja siihen, miten varmenteet ja yksityiset avaimet tallennetaan sisäkkäisiin ”safebag”-rakenteisiin, PKCS#12-tiedostoissa on joitakin yhteensopivuusongelmia, kuten:",[172,1018,1019,1022,1025],{},[175,1020,1021],{},"Windows on tunnettu siitä, että se liittää PKCS#12:n yksityiset avaimet kaikkiin tiedostosta poimittuihin varmenteisiin eikä vain siihen, jolle avain on tarkoitettu. Jos PKCS#12 sisältää varmenneketjun, Windows saattaa näyttää, että sillä on CA-varmenteen yksityinen avain.",[175,1023,1024],{},"macOS:ssä et voi tuoda PKCS#12-tiedostoja, jos salausalgoritmit ovat liian uusia.",[175,1026,1027],{},"Voi olla tarpeen salata PKCS#12-tiedoston varmenteet, jotta vastaanottavat sovellukset saavat ne poimittua. Jotkin niistä tukevat kuitenkin vain hyvin vanhoja ja heikkoja algoritmeja, mikä ei yleensä ole ongelma, koska tieto on joka tapauksessa julkista. OpenSSL 3.x ei kuitenkaan tue näitä vanhoja ja haavoittuvia algoritmeja ja kieltäytyy avaamasta PKCS#12:ta.",[148,1029,1031],{"id":1030},"asn1-ja-pem","ASN.1 ja PEM",[153,1033,1034],{},"Abstract Syntax Notation One (ASN.1) on kieli, jolla kuvataan tietorakenteita. Siinä on joitakin valmiiksi määriteltyjä perustietotyyppejä, kuten kokonaislukuja tai sekvenssejä, ja protokollan tai tiedostomuodon tekijä voi sitten määritellä niiden avulla omia tietotyyppejä.",[165,1036,1038],{"id":1037},"der-koodaus","DER-koodaus",[153,1040,1041,1046],{},[242,1042,1045],{"href":1043,"rel":1044},"https://www.itu.int/rec/T-REC-X.680/",[624],"ITU-T:n standardi X.680"," määrittelee erilaisia koodauksia ASN.1-muodossa määritellylle tiedolle. X.509:ään liittyvässä tiedossa tärkein koodaus on DER, koska tyypin voi koodata vain yhdellä tavalla. Siksi tyypin binäärisen DER-esityksen tiiviste on aina sama, mikä on tärkeää esimerkiksi ASN.1-koodattua tietoa allekirjoitettaessa.",[165,1048,978],{"id":1049},"pem-koodaus",[153,1051,1052,1053,1058],{},"Monissa, mutta ei kaikissa X.509:ään liittyvissä tiedostotyypeissä voit joko tallentaa tiedoston binäärisenä DER-koodauksessa tai lisätä DER-koodauksen päälle vielä ",[242,1054,1057],{"href":1055,"rel":1056},"https://datatracker.ietf.org/doc/html/rfc7468",[624],"PEM-koodauksen",". PEM käyttää vain ASCII-merkkejä, joten sen voi helposti kopioida ja liittää leikepöydän kautta tai, kuten muutama vuosikymmen sitten vielä oli tarpeen, lähettää sähköpostitse.",[165,1060,983],{"id":1061},"työkalut-1",[153,1063,1064,1065,648],{},"Jos sinulla on ASN.1-koodattu tiedosto etkä tiedä, mikä tyyppi se on, tai sinulla ei ole sovellusta kyseiselle tyypille, voit silti purkaa raa’an ASN.1-rakenteen ja katsoa, mitä se kertoo. Windowsissa sisäänrakennettu certutil-työkalu osaa tehdä tämän komennolla ",[803,1066,1067],{},"certutil -decode",{"title":435,"searchDepth":436,"depth":436,"links":1069},[1070,1074,1078,1079,1080],{"id":856,"depth":436,"text":857,"children":1071},[1072,1073],{"id":889,"depth":441,"text":890},{"id":934,"depth":441,"text":935},{"id":945,"depth":436,"text":637,"children":1075},[1076,1077],{"id":965,"depth":441,"text":966},{"id":982,"depth":441,"text":983},{"id":992,"depth":436,"text":642},{"id":1006,"depth":436,"text":1007},{"id":1030,"depth":436,"text":1031,"children":1081},[1082,1083,1084],{"id":1037,"depth":441,"text":1038},{"id":1049,"depth":441,"text":978},{"id":1061,"depth":441,"text":983},{"lang":462,"seoTitle":1086,"titleClass":463,"blogtitlepic":1087,"socialimg":1088,"customExcerpt":1089,"keywords":1090,"asideNav":1091,"maxContent":473},"Tärkeät tietomuodot - X.509, PKCS, ASN.1 ja PEM selitettynä","header-scepman-important-data-formats.png","/blog/heads/header-scepman-important-data-formats.png","Tutustu keskeisiin kryptografian ja varmenteiden muotoihin, kuten X.509, PKCS 7, PKCS 10, PKCS 12, ASN.1 ja PEM.","tärkeät tietomuodot, X.509-varmenne, PKCS-muodot, PKCS 7, PKCS 10, PKCS 12, ASN.1, PEM-muoto, digitaaliset varmenteet, julkisen avaimen infrastruktuuri, PKI-muodot",{"menuItems":1092},[1093,1095,1097,1099,1101],{"href":1094,"text":857},"#x509",{"href":1096,"text":637},"#pkcs7",{"href":1098,"text":642},"#pkcs10",{"href":1100,"text":1007},"#pkcs12",{"href":1102,"text":1031},"#asn1-ja-pem","/glossary/important-data-formats",{"title":851,"description":435},"glossary/important-data-formats","K5mdLOoVteoZhCB0MLbOvyXNlfn5hWzZUAED0cf3sic",{"id":1108,"title":1109,"author":143,"body":1110,"cta":143,"description":435,"eventid":143,"extension":458,"hideInRecent":459,"layout":460,"meta":1333,"moment":143,"navigation":473,"path":1339,"seo":1340,"stem":1341,"tags":143,"webcast":459,"__hash__":1342},"content_fi/glossary/public-key-infrastructure.md","Julkisen avaimen infrastruktuuri",{"type":145,"value":1111,"toc":1322},[1112,1116,1124,1127,1159,1163,1166,1170,1173,1203,1206,1210,1213,1233,1236,1240,1247,1261,1266,1280,1284,1289,1302,1307,1319],[148,1113,1115],{"id":1114},"luottamuksen-rakentaminen","Luottamuksen rakentaminen",[165,1117,1119,1120,1123],{"id":1118},"miten-asiakas-osoittaa-luottavansa-tiettyyn-root-cahan","Miten asiakas ",[157,1121,1122],{},"osoittaa"," luottavansa tiettyyn Root CA:han?",[153,1125,1126],{},"Asiakas osoittaa luottavansa tiettyyn varmenneviranomaiseen (CA) prosessilla, joka perustuu varmenteiden luottamusketjuun. Näin se toimii:",[172,1128,1129,1135,1141,1147,1153],{},[175,1130,1131,1134],{},[157,1132,1133],{},"Esiasennetut juurivarmenteet:"," Useimpien käyttöjärjestelmien ja selainten mukana tulee joukko esiasennettuja juurivarmenteita luotetuilta CA:ilta. Nämä juurivarmenteet tallennetaan luotettujen juurivarmenteiden varastoon.",[175,1136,1137,1140],{},[157,1138,1139],{},"Varmenteen tarkistus:"," Kun asiakas muodostaa yhteyden palvelimeen (esimerkiksi avaa verkkosivuston), palvelin esittää TLS-varmenteensa. Tämän varmenteen on tyypillisesti allekirjoittanut Intermediate CA, jonka varmenteen puolestaan on allekirjoittanut Root CA.",[175,1142,1143,1146],{},[157,1144,1145],{},"Luottamusketjun todentaminen:"," Asiakas todentaa luottamusketjun tarkistamalla, onko esitetyn varmenteen allekirjoittanut luotettu Root CA. Se tarkistaa myös, luotetaanko ketjun Intermediate CA:ihin.",[175,1148,1149,1152],{},[157,1150,1151],{},"Digitaaliset allekirjoitukset:"," Jokaisen ketjun varmenteen on digitaalisesti allekirjoittanut sen yläpuolella oleva CA. Asiakas todentaa nämä allekirjoitukset CA:n julkisella avaimella ja varmistaa näin, ettei varmenteita ole peukaloitu.",[175,1154,1155,1158],{},[157,1156,1157],{},"Luottamuspäätös:"," Jos koko luottamusketju on kelvollinen ja johtaa luotettuun Root CA:han, asiakas luottaa palvelimen varmenteeseen. Näin turvallinen viestintä voi jatkua.",[165,1160,1162],{"id":1161},"mitä-hyötyä-intermediate-caista-on-yhden-ainoan-root-can-sijaan","Mitä hyötyä Intermediate CA:ista on yhden ainoan Root CA:n sijaan?",[153,1164,1165],{},"Infrastruktuuri-PKI:ssä yksi ainoa juuri voi itse asiassa olla eduksi.",[165,1167,1169],{"id":1168},"miten-intermediate-ca-hankkii-varmenteensa","Miten Intermediate CA hankkii varmenteensa?",[153,1171,1172],{},"Intermediate CA eli välitason varmenneviranomainen (CA) hankkii varmenteensa prosessilla, jota kutsutaan Root CA:n tekemäksi ristiinallekirjoitukseksi. Näin se toimii:",[258,1174,1175,1181,1187,1192,1197],{},[175,1176,1177,1180],{},[157,1178,1179],{},"Varmennepyyntö (CSR):"," Organisaatio, joka haluaa pystyttää Intermediate CA:n, luo varmennepyynnön. Varmennepyyntö sisältää Intermediate CA:n julkisen avaimen ja tunnistetiedot.",[175,1182,1183,1186],{},[157,1184,1185],{},"Toimitus Root CA:lle:"," Varmennepyyntö toimitetaan luotetulle Root CA:lle.",[175,1188,1189,1191],{},[157,1190,362],{}," Root CA varmistaa välitason varmennetta pyytävän organisaation identiteetin ja oikeutuksen.",[175,1193,1194,1196],{},[157,1195,350],{}," Kun tarkistus on tehty, Root CA allekirjoittaa varmennepyynnön yksityisellä avaimellaan ja luo näin välitason varmenteen. Tämä allekirjoitettu varmenne kytkee Intermediate CA:n Root CA:han ja muodostaa luottamusketjun.",[175,1198,1199,1202],{},[157,1200,1201],{},"Myöntäminen:"," Root CA myöntää allekirjoitetun välitason varmenteen sitä pyytäneelle organisaatiolle, joka voi sen jälkeen allekirjoittaa sillä loppuentiteettivarmenteita (esimerkiksi verkkosivustojen TLS-varmenteita).",[153,1204,1205],{},"Tämä prosessi varmistaa, että Intermediate CA:han luotetaan sen Root CA -kytköksen ansiosta, sillä Root CA:han luottavat jo selaimet ja käyttöjärjestelmät.",[165,1207,1209],{"id":1208},"mikä-on-varmenneketju-miten-se-toimii","Mikä on varmenneketju? Miten se toimii?",[153,1211,1212],{},"Varmenneketju, jota kutsutaan myös luottamusketjuksi, on varmenteiden sarja, joka varmistaa digitaalisen varmenteen aitouden ja luotettavuuden. Näin se toimii:",[172,1214,1215,1221,1227],{},[175,1216,1217,1220],{},[157,1218,1219],{},"Todentamisprosessi:"," Kun asiakas (kuten selain) muodostaa yhteyden palvelimeen, palvelin esittää loppuentiteettivarmenteensa. Asiakas käy sitten läpi varmenneketjun ja varmistaa, että jokaisen varmenteen on allekirjoittanut ketjun seuraava varmenne aina juurivarmenteeseen asti.",[175,1222,1223,1226],{},[157,1224,1225],{},"Luottamusketju:"," Jokainen ketjun varmenne todennetaan sen yläpuolella olevan varmenteen julkisella avaimella. Tämä jatkuu juurivarmenteeseen asti, johon asiakas jo luottaa.",[175,1228,1229,1232],{},[157,1230,1231],{},"Luottamuksen syntyminen:"," Jos koko ketju on kelvollinen ja johtaa luotettuun juurivarmenteeseen, asiakas luottaa loppuentiteettivarmenteeseen ja turvallinen viestintä voi jatkua.",[153,1234,1235],{},"Tämä järjestelmä varmistaa, että loppuentiteettivarmenne on aito ja luotetun viranomaisen myöntämä, mikä säilyttää digitaalisen viestinnän eheyden ja tietoturvan.",[165,1237,1239],{"id":1238},"mitä-ongelmaa-basic-constraints-laajennus-pyrkii-ratkaisemaan","Mitä ongelmaa Basic Constraints -laajennus pyrkii ratkaisemaan?",[153,1241,1242,1243,1246],{},"Digitaalisen varmenteen ",[157,1244,1245],{},"Basic Constraints"," -laajennus ratkaisee ongelman, joka koskee erilaisten varmennetyyppien ja niiden roolien erottamista toisistaan julkisen avaimen infrastruktuurissa (PKI). Näin se toimii:",[172,1248,1249,1255],{},[175,1250,1251,1254],{},[157,1252,1253],{},"Varmenneviranomaisen (CA) tunnistaminen:"," Se määrittää, onko varmenne CA-varmenne vai loppuentiteettivarmenne. Tämä ero on ratkaiseva, koska CA-varmenteilla voidaan myöntää muita varmenteita, kun taas loppuentiteettivarmenteilla ei voi.",[175,1256,1257,1260],{},[157,1258,1259],{},"Polun pituusrajoite:"," Se voi rajoittaa sitä, montako Intermediate CA:ta tämän CA:n alapuolella voi varmenneketjussa olla. Näin estetään liian pitkät varmenneketjut, jotka voivat olla tehottomia ja mahdollisesti turvattomia.",[153,1262,1263],{},[157,1264,1265],{},"Ratkaistut ongelmat:",[172,1267,1268,1274],{},[175,1269,1270,1273],{},[157,1271,1272],{},"Luvattoman varmenteiden myöntämisen estäminen:"," Merkitsemällä selvästi, mitkä varmenteet voivat toimia CA:ina, estetään loppuentiteettivarmenteita myöntämästä muita varmenteita, jolloin PKI:n eheys säilyy.",[175,1275,1276,1279],{},[157,1277,1278],{},"Varmenneketjun pituuden hallinta:"," Polun pituuden rajoittaminen pitää varmenneketjun hallittavana ja turvallisena sekä estää pitkiin ketjuihin liittyvät mahdolliset haavoittuvuudet",[165,1281,1283],{"id":1282},"mitä-mekanismeja-se-käyttää-näiden-ongelmien-ratkaisemiseen"," Mitä mekanismeja se käyttää näiden ongelmien ratkaisemiseen?",[153,1285,1242,1286,1288],{},[157,1287,1245],{}," -laajennus käyttää seuraavia mekanismeja ratkaistakseen ongelmat, jotka koskevat CA-varmenteiden erottamista loppuentiteettivarmenteista ja varmenneketjun pituuden hallintaa:",[172,1290,1291,1297],{},[175,1292,1293,1296],{},[157,1294,1295],{},"CA-lippu:"," Tämä lippu kertoo, onko varmenne varmenneviranomaisen (CA) varmenne vai loppuentiteettivarmenne. Jos lipun arvo on TRUE, varmenteella voidaan allekirjoittaa muita varmenteita, eli kyseessä on CA-varmenne. Jos arvo on FALSE, kyseessä on loppuentiteettivarmenne, jolla ei voi myöntää muita varmenteita.",[175,1298,1299,1301],{},[157,1300,1259],{}," Tämä määrittää, montako muun myöntämää välitason varmennetta voi enintään seurata tätä varmennetta kelvollisessa varmennepolussa. Rajoitteen avulla laajennus rajaa varmenneketjun pituutta ja pitää sen hallittavana ja turvallisena.",[153,1303,1304],{},[157,1305,1306],{},"Miten nämä mekanismit toimivat:",[172,1308,1309,1314],{},[175,1310,1311,1313],{},[157,1312,1295],{}," Kun varmenne myönnetään, CA-lippu asetetaan varmenteen käyttötarkoituksen mukaisesti. Varmenteen tarkistuksen aikana asiakkaat katsovat tätä lippua ja päättelevät, voiko varmenteeseen luottaa muiden varmenteiden myöntäjänä.",[175,1315,1316,1318],{},[157,1317,1259],{}," Tämä arvo tarkistetaan tarkistusprosessin aikana sen varmistamiseksi, ettei varmenneketju ylitä määritettyä pituutta. Jos ketju on liian pitkä, varmennetta pidetään virheellisenä.",[153,1320,1321],{},"Nämä mekanismit auttavat säilyttämään julkisen avaimen infrastruktuurin (PKI) eheyden ja tietoturvan varmistamalla, että vain valtuutetut varmenteet voivat myöntää muita varmenteita, ja estämällä liian pitkät varmenneketjut.",{"title":435,"searchDepth":436,"depth":436,"links":1323},[1324],{"id":1114,"depth":436,"text":1115,"children":1325},[1326,1328,1329,1330,1331,1332],{"id":1118,"depth":441,"text":1327},"Miten asiakas osoittaa luottavansa tiettyyn Root CA:han?",{"id":1161,"depth":441,"text":1162},{"id":1168,"depth":441,"text":1169},{"id":1208,"depth":441,"text":1209},{"id":1238,"depth":441,"text":1239},{"id":1282,"depth":441,"text":1283},{"lang":462,"seoTitle":1334,"titleClass":463,"socialimg":1335,"blogtitlepic":1336,"customExcerpt":1337,"keywords":1338,"maxContent":473},"Luottamuksen rakentaminen julkisen avaimen infrastruktuurissa: PKI:n varmenneluottamusmalli","/blog/heads/header-scepman-public-key-infrastructure.png","header-scepman-public-key-infrastructure.png","Rakenna luottamus PKI:ssä varmenneketjujen, Root CA:iden ja Intermediate CA:iden sekä varmenteiden turvallisen tarkistuksen avulla.","luottamuksen rakentaminen PKI, julkisen avaimen infrastruktuurin luottamus, varmenteiden luottamusketju, Root CA -luottamus, Intermediate CA -luottamus, PKI-luottamusmalli, varmenteen tarkistus, luotetut juurivarmenteet, varmenteen turvallinen todentaminen, luottamusketjun todentaminen","/glossary/public-key-infrastructure",{"title":1109,"description":435},"glossary/public-key-infrastructure","N_QXb7-WRqBdt6HXDMVLw9VjA4yL0gnpuiLLH2wxKKA",{"id":1344,"title":1345,"author":143,"body":1346,"cta":143,"description":435,"eventid":143,"extension":458,"hideInRecent":459,"layout":460,"meta":1784,"moment":143,"navigation":473,"path":1790,"seo":1791,"stem":1792,"tags":143,"webcast":459,"__hash__":1793},"content_fi/glossary/use-cases-for-certificates.md","Varmenteiden käyttötapaukset",{"type":145,"value":1347,"toc":1769},[1348,1352,1356,1370,1374,1406,1410,1440,1444,1450,1456,1460,1513,1517,1521,1535,1539,1551,1555,1558,1572,1576,1582,1593,1598,1609,1615,1626,1630,1650,1654,1657,1661,1681,1685,1702,1707,1727,1731,1734,1766],[148,1349,1351],{"id":1350},"transport-layer-security-tls","Transport Layer Security (TLS)",[165,1353,1355],{"id":1354},"mitkä-kaksi-kysymystä-asiakkaan-on-esitettävä-saadessaan-varmenteen-palvelimelta","Mitkä kaksi kysymystä asiakkaan on esitettävä saadessaan varmenteen palvelimelta?",[258,1357,1358,1364],{},[175,1359,1360,1363],{},[157,1361,1362],{},"Onko varmenne voimassa ja luotettava?"," Asiakkaan on varmistettava, että varmenteen on myöntänyt luotettu varmenneviranomainen (CA) ja ettei varmenne ole vanhentunut tai peruutettu. Tähän kuuluu varmenteen voimassaoloajan tarkistaminen ja sen varmistaminen, että varmenteen on allekirjoittanut asiakkaan luottama CA.",[175,1365,1366,1369],{},[157,1367,1368],{},"Vastaako varmenne palvelimen identiteettiä?"," Asiakkaan on varmistettava, että varmenteen tiedot, kuten Common Name (CN) tai Subject Alternative Name (SAN), vastaavat palvelimen verkkotunnusta. Näin vahvistetaan, että varmenne on todella tarkoitettu sille palvelimelle, johon asiakas yrittää ottaa yhteyttä.",[165,1371,1373],{"id":1372},"miten-asiakas-varmistaa-että-varmenteeseen-voi-luottaa","Miten asiakas varmistaa, että varmenteeseen voi luottaa?",[258,1375,1376,1382,1388,1394,1400],{},[175,1377,1378,1381],{},[157,1379,1380],{},"Varmenteiden luottamusketjun tarkistaminen:"," Asiakas todentaa varmenneketjun, johon kuuluvat palvelimen varmenne, mahdolliset välitason varmenteet ja juurivarmenne. Jokaisen ketjun varmenteen on oltava seuraavan, ylemmän viranomaisen allekirjoittama, ja ketjun on lopulta päädyttävä luotettuun juurivarmenteeseen.",[175,1383,1384,1387],{},[157,1385,1386],{},"Varmenteen voimassaoloajan todentaminen:"," Asiakas tarkistaa varmenteen voimassaoloajan varmistaakseen, ettei varmenne ole vanhentunut eikä vielä voimaan tulematta. Tähän kuuluu varmenteen ”Not Before”- ja ”Not After” -päivämäärien tarkistaminen.",[175,1389,1390,1393],{},[157,1391,1392],{},"Varmenteen täsmäyttäminen palvelimen identiteettiin:"," Asiakas varmistaa, että varmenteen Common Name (CN) tai Subject Alternative Name (SAN) vastaa palvelimen verkkotunnusta. Tämä vahvistaa, että varmenne on tarkoitettu sille palvelimelle, johon asiakas ottaa yhteyttä.",[175,1395,1396,1399],{},[157,1397,1398],{},"Peruutuksen tarkistaminen:"," Asiakas tarkistaa, onko varmenne peruutettu, kysymällä sulkulistalta (CRL) tai käyttämällä Online Certificate Status Protocolia (OCSP). Peruutettuun varmenteeseen ei enää luoteta.",[175,1401,1402,1405],{},[157,1403,1404],{},"Digitaalisen allekirjoituksen todentaminen:"," Asiakas todentaa varmenteen digitaalisen allekirjoituksen varmistaakseen, ettei varmennetta ole peukaloitu. Tähän kuuluu kryptografisen allekirjoituksen tarkistaminen myöntävän CA:n julkisella avaimella.",[165,1407,1409],{"id":1408},"miten-asiakas-varmistaa-että-palvelin-on-varmenteen-todellinen-omistaja","Miten asiakas varmistaa, että palvelin on varmenteen todellinen omistaja?",[258,1411,1412,1418,1424,1429,1435],{},[175,1413,1414,1417],{},[157,1415,1416],{},"Varmenneketjun todentaminen:"," Asiakas todentaa varmenneketjun ja varmistaa, että jokaisen ketjun varmenteen on allekirjoittanut luotettu varmenneviranomainen (CA). Ketju alkaa palvelimen varmenteesta ja päättyy luotettuun juurivarmenteeseen.",[175,1419,1420,1423],{},[157,1421,1422],{},"Verkkotunnuksen täsmäytys:"," Asiakas tarkistaa, että varmenteen Common Name (CN) tai Subject Alternative Name (SAN) vastaa palvelimen verkkotunnusta. Näin varmistetaan, että varmenne on tarkoitettu sille palvelimelle, johon asiakas ottaa yhteyttä.",[175,1425,1426,1428],{},[157,1427,1404],{}," Asiakas todentaa varmenteen digitaalisen allekirjoituksen myöntävän CA:n julkisella avaimella. Näin varmistetaan, ettei varmennetta ole peukaloitu ja että sen on todella myöntänyt luotettu CA.",[175,1430,1431,1434],{},[157,1432,1433],{},"Varmenteen voimassaoloaika:"," Asiakas tarkistaa varmenteen voimassaoloajan varmistaakseen, että varmenne on parhaillaan voimassa eikä ole vanhentunut.",[175,1436,1437,1399],{},[157,1438,1439],{},"Peruutustilanteen tarkistus:",[165,1441,1443],{"id":1442},"miksi-omistajuudella-on-merkitystä-jos-olet-jo-tarkistanut-että-varmenteeseen-luotetaan","Miksi omistajuudella on merkitystä, jos olet jo tarkistanut, että varmenteeseen luotetaan?",[153,1445,1446,1449],{},[157,1447,1448],{},"Varmenteen voimassaolo ja luotettavuus:"," Tämä vaihe varmistaa, että varmenteen on myöntänyt luotettu varmenneviranomainen (CA), että se on voimassaoloaikansa sisällä ja ettei sitä ole peruutettu. Se vahvistaa, että varmenne on aito eikä sitä ole peukaloitu.",[153,1451,1452,1455],{},[157,1453,1454],{},"Palvelimen identiteetin todentaminen:"," Vaikka varmenne olisi voimassa ja luotettava, on lisäksi vahvistettava, että se kuuluu juuri sille palvelimelle, johon olet yhteydessä. Tähän kuuluu sen tarkistaminen, että varmenteen Common Name (CN) tai Subject Alternative Name (SAN) vastaa palvelimen verkkotunnusta. Tämä vaihe varmistaa, että varmenne on tarkoitettu juuri kyseiselle palvelimelle, ja estää välimieshyökkäykset, joissa hyökkääjä voisi esittää voimassa olevan varmenteen toiselle verkkotunnukselle.",[165,1457,1459],{"id":1458},"millä-kahdella-menetelmällä-asiakas-vastaa-tähän-kysymykseen-mitkä-kaksi-tulosta-kummastakin-menetelmästä-seuraa","Millä kahdella menetelmällä asiakas vastaa tähän kysymykseen? Mitkä kaksi tulosta kummastakin menetelmästä seuraa?",[258,1461,1462,1489],{},[175,1463,1464,1467,1468,1471,1474,1475],{},[157,1465,1466],{},"Domain Name System (DNS) -todentaminen:"," Asiakas tarkistaa, että varmenteen Common Name (CN) tai Subject Alternative Name (SAN) vastaa palvelimen verkkotunnusta. ",[1469,1470],"br",{},[157,1472,1473],{},"Tulos",":",[172,1476,1477,1483],{},[175,1478,1479,1482],{},[157,1480,1481],{},"Täsmää",": Jos nimet täsmäävät, asiakas voi jatkaa yhteyden muodostamista luottaen siihen, että varmenne on tarkoitettu kyseiselle palvelimelle. ",[175,1484,1485,1488],{},[157,1486,1487],{},"Ei täsmää",": Jos nimet eivät täsmää, asiakas todennäköisesti katkaisee yhteyden tai näyttää varoituksen, joka kertoo mahdollisesta tietoturvariskistä.",[175,1490,1491,1494,1495,1497,1474,1499],{},[157,1492,1493],{},"Julkisen avaimen infrastruktuurin (PKI) todentaminen:"," Asiakas todentaa varmenteen digitaalisen allekirjoituksen myöntävän varmenneviranomaisen (CA) julkisella avaimella. ",[1469,1496],{},[157,1498,1473],{},[172,1500,1501,1507],{},[175,1502,1503,1506],{},[157,1504,1505],{},"Kelvollinen allekirjoitus",": Jos allekirjoitus on kelvollinen, se vahvistaa, ettei varmennetta ole peukaloitu ja että sen on myöntänyt luotettu CA.",[175,1508,1509,1512],{},[157,1510,1511],{},"Virheellinen allekirjoitus:"," Jos allekirjoitus on virheellinen, asiakas katkaisee yhteyden tai näyttää varoituksen, joka kertoo, että varmenne voi olla vaarantunut tai väärennetty.",[165,1514,1516],{"id":1515},"mikä-ratkaisee-kumpaa-menetelmää-käytetään","Mikä ratkaisee, kumpaa menetelmää käytetään?",[153,1518,1519],{},[157,1520,1466],{},[172,1522,1523,1529],{},[175,1524,1525,1528],{},[157,1526,1527],{},"Käyttö",": Tätä menetelmää käytetään aina osana TLS-kättelyä. Asiakas vertaa varmenteen Common Name (CN)- tai Subject Alternative Name (SAN) -tietoa palvelimen verkkotunnukseen varmistaakseen, että ne täsmäävät.",[175,1530,1531,1534],{},[157,1532,1533],{},"Ratkaisevat tekijät:"," Tämä on TLS-protokollan vakio-osa, ja asiakas tekee sen automaattisesti muodostaessaan suojattua yhteyttä.",[153,1536,1537],{},[157,1538,1493],{},[172,1540,1541,1546],{},[175,1542,1543,1545],{},[157,1544,1527],{},": Myös tätä menetelmää käytetään aina TLS-kättelyn aikana. Asiakas todentaa varmenteen digitaalisen allekirjoituksen myöntävän varmenneviranomaisen (CA) julkisella avaimella.",[175,1547,1548,1550],{},[157,1549,1533],{}," Tämäkin on TLS-protokollan vakio-osa. Asiakas tekee tämän tarkistuksen automaattisesti varmistaakseen, että varmenne on voimassa eikä sitä ole peukaloitu.",[148,1552,1554],{"id":1553},"mitkä-varmenteet-palvelimen-pitäisi-lähettää-asiakkaalle","Mitkä varmenteet palvelimen pitäisi lähettää asiakkaalle?",[153,1556,1557],{},"TLS-kättelyn aikana palvelimen pitäisi lähettää asiakkaalle seuraavat varmenteet:",[172,1559,1560,1566],{},[175,1561,1562,1565],{},[157,1563,1564],{},"Loppuentiteettivarmenne:"," Tämä on palvelimen oma varmenne, jolla se todistaa identiteettinsä asiakkaalle.",[175,1567,1568,1571],{},[157,1569,1570],{},"Välitason varmenteet:"," Nämä varmenteet yhdistävät loppuentiteettivarmenteen luotettuun juurivarmenteeseen. Ne auttavat muodostamaan luottamusketjun palvelimen varmenteesta takaisin luotettuun juurivarmenteeseen.",[148,1573,1575],{"id":1574},"mitä-ovat-domain-validation-ja-extended-validation-varmenteet","Mitä ovat Domain Validation- ja Extended Validation -varmenteet?",[153,1577,1578,1581],{},[157,1579,1580],{},"Domain Validation (DV) -varmenteet"," ovat TLS-varmennetyyppi, jossa varmenneviranomainen (CA) tarkistaa, että hakija hallitsee verkkotunnusta. Tämä tehdään tyypillisesti näin:",[172,1583,1584,1587,1590],{},[175,1585,1586],{},"Vastataan verkkotunnuksen hallinnolliseen yhteysosoitteeseen lähetettyyn sähköpostiin.",[175,1588,1589],{},"Lisätään DNS:ään TXT-tietue.",[175,1591,1592],{},"Ladataan tiedosto verkkopalvelimelle.",[153,1594,1595],{},[157,1596,1597],{},"Keskeiset ominaisuudet:",[172,1599,1600,1603,1606],{},[175,1601,1602],{},"Nopea myöntäminen: Ne voidaan myöntää nopeasti, usein minuuteissa, koska ne vaativat vain vähän tarkistuksia.",[175,1604,1605],{},"Perustason tietoturva: Ne tarjoavat salauksen ja perustason varmuuden siitä, että verkkotunnus on varmennetta pyytäneen tahon hallinnassa.",[175,1607,1608],{},"Kustannustehokkuus: Usein halvempia tai jopa ilmaisia, joten ne sopivat hyvin pienille sivustoille ja henkilökohtaisiin projekteihin.",[153,1610,1611,1614],{},[157,1612,1613],{},"Extended Validation (EV) -varmenteet"," ovat korkeamman tason TLS-varmenteita, jotka edellyttävät perusteellisempaa tarkistusprosessia. CA varmistaa varmennetta pyytävän tahon oikeudellisen, fyysisen ja toiminnallisen olemassaolon. Tähän kuuluu:",[172,1616,1617,1620,1623],{},[175,1618,1619],{},"Tahon oikeudellisen identiteetin ja aseman vahvistaminen.",[175,1621,1622],{},"Tahon fyysisen ja toiminnallisen läsnäolon todentaminen.",[175,1624,1625],{},"Sen varmistaminen, että taholla on yksinoikeus verkkotunnuksen käyttöön.",[153,1627,1628],{},[157,1629,1597],{},[172,1631,1632,1638,1644],{},[175,1633,1634,1637],{},[157,1635,1636],{},"Korkea varmuus:"," Tarjoaa käyttäjille korkeimman luottamuksen ja varmuuden tason, koska taustalla on perusteellinen tarkistus.",[175,1639,1640,1643],{},[157,1641,1642],{},"Näkyvät tunnisteet:"," Joissakin selaimissa EV-varmenteet näyttivät aiemmin organisaation nimen osoiterivillä, joskin tämä on nykyään harvinaisempaa.",[175,1645,1646,1649],{},[157,1647,1648],{},"Vahvempi luottamus:"," Sopii ihanteellisesti sivustoille, jotka käsittelevät arkaluonteisia tietoja, kuten rahoituslaitoksille ja verkkokaupoille.",[165,1651,1653],{"id":1652},"kummat-ovat-turvallisempia"," Kummat ovat turvallisempia?",[153,1655,1656],{},"Extended Validation (EV) -varmenteita pidetään yleisesti turvallisempina kuin Domain Validation (DV) -varmenteita, koska niiden tarkistusprosessi on perusteellisempi. Tässä vertailu:",[153,1658,1659],{},[157,1660,1580],{},[172,1662,1663,1669,1675],{},[175,1664,1665,1668],{},[157,1666,1667],{},"Tarkistuksen taso:"," Todentaa vain verkkotunnuksen hallinnan.",[175,1670,1671,1674],{},[157,1672,1673],{},"Tietoturva:"," Tarjoaa perustason salauksen ja varmuuden.",[175,1676,1677,1680],{},[157,1678,1679],{},"Käyttötapaus:"," Sopii henkilökohtaisille sivustoille, blogeille ja pienyrityksille.",[153,1682,1683],{},[157,1684,1613],{},[172,1686,1687,1692,1697],{},[175,1688,1689,1691],{},[157,1690,1667],{}," Todentaa tahon oikeudellisen, fyysisen ja toiminnallisen olemassaolon.",[175,1693,1694,1696],{},[157,1695,1673],{}," Tarjoaa korkeamman luottamuksen ja varmuuden tason perusteellisen tarkistuksen ansiosta.",[175,1698,1699,1701],{},[157,1700,1679],{}," Sopii ihanteellisesti rahoituslaitoksille, verkkokaupoille ja kaikille sivustoille, jotka käsittelevät arkaluonteisia tietoja.",[153,1703,1704],{},[157,1705,1706],{},"Miksi EV-varmenteet ovat turvallisempia:",[172,1708,1709,1715,1721],{},[175,1710,1711,1714],{},[157,1712,1713],{},"Perusteellinen tarkistus:"," EV-varmenteet edellyttävät laajaa tarkistusta, mikä vaikeuttaa niiden hankkimista pahantahtoisille tahoille.",[175,1716,1717,1720],{},[157,1718,1719],{},"Luottamuksen tunnisteet:"," Vaikka tämä on nykyään harvinaisempaa, EV-varmenteet näyttivät aiemmin organisaation nimen selaimen osoiterivillä ja antoivat käyttäjille näkyvän varmuuden.",[175,1722,1723,1726],{},[157,1724,1725],{},"Korkeampi varmuus:"," Yksityiskohtainen todentamisprosessi varmistaa, että varmenteen takana oleva taho on aito, mikä pienentää tietojenkalastelun ja muiden hyökkäysten riskiä.",[148,1728,1730],{"id":1729},"miten-peruutusprosessi-toimii-ocsp-stapling-menetelmällä","Miten peruutusprosessi toimii OCSP Stapling -menetelmällä",[153,1732,1733],{},"OCSP Stapling parantaa tavanomaista OCSP-prosessia pienentämällä viivettä ja parantamalla yksityisyyttä. Näin se toimii:",[258,1735,1736,1742,1748,1754,1760],{},[175,1737,1738,1741],{},[157,1739,1740],{},"Palvelin pyytää OCSP-vastauksen:"," Verkkopalvelin kysyy säännöllisin väliajoin varmenteensa peruutustilanteen OCSP-vastaajalta (palvelimelta, jota varmenneviranomainen eli CA ylläpitää). Pyyntö tehdään taustalla eikä jokaisen asiakasyhteyden yhteydessä.",[175,1743,1744,1747],{},[157,1745,1746],{},"OCSP-vastaaja antaa vastauksen:"," OCSP-vastaaja lähettää takaisin allekirjoitetun ja aikaleimatun OCSP-vastauksen, joka kertoo varmenteen tilan (esimerkiksi ”good”, ”revoked” tai ”unknown”). Palvelin tallentaa vastauksen välimuistiin.",[175,1749,1750,1753],{},[157,1751,1752],{},"TLS-kättely niitatulla vastauksella:"," Kun asiakas (esimerkiksi selain) avaa yhteyden palvelimeen, palvelin sisällyttää välimuistissa olevan OCSP-vastauksen TLS-kättelyyn. Tätä kutsutaan vastauksen ”niittaamiseksi” kättelyyn.",[175,1755,1756,1759],{},[157,1757,1758],{},"Asiakas todentaa OCSP-vastauksen:"," Asiakas todentaa niitatun OCSP-vastauksen. Koska CA on allekirjoittanut vastauksen, asiakas voi luottaa sen paikkansapitävyyteen. Jos vastaus kertoo varmenteen olevan peruutettu, asiakas ei muodosta suojattua yhteyttä.",[175,1761,1762,1765],{},[157,1763,1764],{},"Säännölliset päivitykset:"," Palvelin päivittää välimuistissa olevan OCSP-vastauksensa säännöllisesti, jotta sillä on aina ajantasainen tila annettavana TLS-kättelyn aikana.",[153,1767,1768],{},"Tämä prosessi vähentää asiakkaiden tarvetta tehdä erillisiä OCSP-pyyntöjä ja parantaa siten suorituskykyä ja yksityisyyttä.",{"title":435,"searchDepth":436,"depth":436,"links":1770},[1771,1779,1780,1783],{"id":1350,"depth":436,"text":1351,"children":1772},[1773,1774,1775,1776,1777,1778],{"id":1354,"depth":441,"text":1355},{"id":1372,"depth":441,"text":1373},{"id":1408,"depth":441,"text":1409},{"id":1442,"depth":441,"text":1443},{"id":1458,"depth":441,"text":1459},{"id":1515,"depth":441,"text":1516},{"id":1553,"depth":436,"text":1554},{"id":1574,"depth":436,"text":1575,"children":1781},[1782],{"id":1652,"depth":441,"text":1653},{"id":1729,"depth":436,"text":1730},{"lang":462,"seoTitle":1785,"titleClass":463,"socialimg":1786,"blogtitlepic":1787,"customExcerpt":1788,"keywords":1789,"maxContent":473},"Transport Layer Security (TLS): varmenteiden käyttötapaukset ja tarkistus","/blog/heads/header-scepman-use-cases-certificates.png","header-scepman-use-cases-certificates.png","Suojaa verkkosivustosi ja käyttäjäsi TLS-varmenteilla, jotka todentavat palvelimet, rakentavat luottamusta varmenneketjujen avulla ja takaavat turvalliset, salatut yhteydet.","TLS-varmenteet, Transport Layer Security, varmenteiden käyttötapaukset, TLS-varmenteen tarkistus, varmenteiden luottamusketju, DV-varmenteet, EV-varmenteet, palvelimen todennus, turvalliset yhteydet, OCSP-stapling","/glossary/use-cases-for-certificates",{"title":1345,"description":435},"glossary/use-cases-for-certificates","fH2xFwC___P0AR5de_8-ENOYseORB4j0g70_c1R7M-g",{"list":139,"authors":143},1790098989970]