[{"data":1,"prerenderedAt":1798},["ShallowReactive",2],{"sc:header-data-no":3,"sc:footer-data-no":101,"glossary-posts-no":139,"content-no-list-c077398beed29":1797},{"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",{"no":10},{"title":11,"url":12,"alt":13},"Hjem","/no","SCEPman",[15,19,25,31,83,89],{"name":16,"languages":17},"nav-home",{"no":18},{"title":11,"url":12},{"name":20,"languages":21},"pricing",{"no":22},{"title":23,"url":24},"Priser","/no/pricing",{"name":26,"languages":27},"partner",{"no":28},{"title":29,"url":30},"Partnere","/no/partner",{"name":32,"languages":33,"children":36},"support-hub",{"no":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",{"no":44},{"title":45,"url":46},"Docs","https://docs.scepman.com/",{"name":48,"languages":49},"faq",{"no":50},{"title":51,"url":52},"FAQ","/no/faq",{"name":54,"children":55},"support-hub-group-2",[56,62],{"name":57,"target":42,"languages":58},"support-ticket",{"no":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",{"no":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",{"no":74},{"title":75,"url":76},"Ordliste","/no/glossary",{"name":78,"languages":79},"blog",{"no":80},{"title":81,"url":82},"Blogg","/no/blog",{"name":84,"languages":85},"events",{"no":86},{"title":87,"url":88},"Arrangementer","/no/events",{"name":90,"languages":91},"about",{"no":92},{"title":93,"url":94},"Om oss","/no/about-us",{"name":96,"languages":97},"contact",{"no":98},{"title":99,"url":100},"support@scepman.com","mailto:support@scepman.com",{"data":102},{"mail":103,"logos":104,"socials":109,"links":122,"linksNo":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},"Personvern",{"title":136,"url":128,"target":42},"Juridisk informasjon",{"title":138,"url":131,"target":42},"Kontakt og kontorer",[140,478,850,1109,1345],{"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_no/glossary/cryptography.md","Kryptografi",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},"hvilke-to-typer-nøkkelbasert-kryptering-finnes","Hvilke to typer nøkkelbasert kryptering finnes?",[153,154,155,156,160,161],"p",{},"De to hovedtypene nøkkelbasert kryptering er ",[157,158,159],"strong",{},"symmetrisk kryptering"," og ",[157,162,163],{},"asymmetrisk kryptering.",[165,166,168],"h3",{"id":167},"symmetrisk-kryptering",[157,169,170],{},"Symmetrisk kryptering",[172,173,174,181,187,193],"ul",{},[175,176,177,180],"li",{},[157,178,179],{},"Nøkkelbruk",": Bruker én og samme nøkkel til både kryptering og dekryptering.",[175,182,183,186],{},[157,184,185],{},"Hastighet",": Som regel raskere og mer effektiv.",[175,188,189,192],{},[157,190,191],{},"Sikkerhet",": Hovedutfordringen er å dele nøkkelen mellom partene på en sikker måte.",[175,194,195,198],{},[157,196,197],{},"Eksempler",": AES (Advanced Encryption Standard), DES (Data Encryption Standard).",[165,200,202],{"id":201},"asymmetrisk-kryptering",[157,203,204],{},"Asymmetrisk kryptering",[172,206,207,212,217,222],{},[175,208,209,211],{},[157,210,179],{},": Bruker et nøkkelpar, en offentlig nøkkel til kryptering og en privat nøkkel til dekryptering.",[175,213,214,216],{},[157,215,185],{},": Tregere enn symmetrisk kryptering fordi beregningene er mer komplekse.",[175,218,219,221],{},[157,220,191],{},": Sikrere ved distribusjon av nøkler, siden den private nøkkelen aldri deles.",[175,223,224,226],{},[157,225,197],{},": RSA (Rivest-Shamir-Adleman), ECC (Elliptic Curve Cryptography).",[165,228,230],{"id":229},"hvilken-type-kryptering-regnes-som-sikrest","Hvilken type kryptering regnes som sikrest?",[153,232,233],{},"Begge ordningene regnes som sikre, i den forstand at ingen dagens datamaskiner kan bryte chifferet så lenge du bruker en moderne algoritme med tilstrekkelig nøkkellengde.",[153,235,236],{},"Hvilken type kryptering som er best, avhenger av bruksområdet, men mange bruksområder krever asymmetrisk kryptering fordi den bruker et nøkkelpar: en offentlig nøkkel til kryptering og en privat nøkkel til dekryptering. Den private nøkkelen holdes hemmelig, noe som styrker sikkerheten siden den aldri trenger å deles.",[165,238,240,241],{"id":239},"hvilken-type-kryptering-egner-seg-best-til-store-datamengder","Hvilken type kryptering egner seg best til store datamengder? ",[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],{},"Symmetrisk kryptering, fordi den er raskere.",[165,250,252,253],{"id":251},"hvordan-foregår-hybrid-kryptering","Hvordan foregår hybrid kryptering? ",[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],{},"Nøkkelgenerering",": Avsenderen genererer en ny symmetrisk nøkkel (også kalt øktnøkkel) for å kryptere selve meldingen.",[175,267,268,271],{},[157,269,270],{},"Kryptering av meldingen",": Avsenderen bruker den symmetriske nøkkelen til å kryptere klartekstmeldingen, og resultatet er en chiffertekst.",[175,273,274,277],{},[157,275,276],{},"Kryptering av nøkkelen",": Deretter krypterer avsenderen den symmetriske nøkkelen med mottakerens offentlige nøkkel (asymmetrisk kryptering).",[175,279,280,283],{},[157,281,282],{},"Overføring",": Avsenderen sender både den krypterte meldingen (chifferteksten) og den krypterte symmetriske nøkkelen til mottakeren.",[175,285,286,289],{},[157,287,288],{},"Dekryptering av nøkkelen",": Mottakeren bruker sin private nøkkel til å dekryptere den symmetriske nøkkelen.",[175,291,292,295],{},[157,293,294],{},"Dekryptering av meldingen",": Til slutt bruker mottakeren den dekrypterte symmetriske nøkkelen til å dekryptere chifferteksten og hente fram den opprinnelige klarteksten.",[148,297,299],{"id":298},"hashalgoritmer","Hashalgoritmer",[153,301,302],{},"En hashalgoritme er en matematisk funksjon som gjør inndata av vilkårlig størrelse om til en tegnstreng med fast lengde, vanligvis en rekke bokstaver og tall. Resultatet kalles en hashverdi eller digest.",[165,304,306],{"id":305},"hva-er-en-kollisjon","Hva er en kollisjon?",[153,308,309],{},"En kollisjon i hashing oppstår når to forskjellige datasett gir samme hashverdi med den samme hashalgoritmen. Det er problematisk, fordi hovedformålet med en hashalgoritme er å representere ulike inndata entydig.",[165,311,313],{"id":312},"hva-er-en-mac","Hva er en MAC?",[153,315,316],{},"Message Authentication Code (MAC): I kryptografien er en MAC en kort informasjonsbit som brukes til å autentisere en melding og sikre integriteten til den. Den bekrefter at meldingen ikke er endret, og verifiserer avsenderens identitet.",[165,318,320],{"id":319},"hva-skiller-en-mac-fra-en-hmac","Hva skiller en MAC fra en HMAC?",[153,322,323],{},"MAC: En generell betegnelse på en kode som verifiserer integriteten og ektheten til en melding, enten ved hjelp av blokkchiffer eller hashfunksjoner.",[153,325,326],{},"HMAC: En bestemt type MAC som bruker en kryptografisk hashfunksjon og en hemmelig nøkkel, og som gir sterkere sikkerhetsegenskaper.",[148,328,330],{"id":329},"asymmetrisk-kryptografi","Asymmetrisk kryptografi",[165,332,334],{"id":333},"hvordan-foregår-signering-av-meldinger","Hvordan foregår signering av meldinger?",[153,336,337],{},"Signering av meldinger er en kryptografisk prosess som brukes til å verifisere at en melding er ekte og uendret.",[258,339,340,346,352,358],{},[175,341,342,345],{},[157,343,344],{},"Oppretting av hashverdi:"," Avsenderen genererer et unikt digitalt fingeravtrykk (en hashverdi) av meldingen med en kryptografisk hashfunksjon, for eksempel SHA-256. Denne hashverdien representerer innholdet i meldingen entydig.",[175,347,348,351],{},[157,349,350],{},"Signering:"," Avsenderen krypterer hashverdien med sin private nøkkel og skaper dermed den digitale signaturen. Slik kan signaturen bare genereres av noen som har tilgang til avsenderens private nøkkel.",[175,353,354,357],{},[157,355,356],{},"Sending:"," Den digitale signaturen legges ved meldingen, og begge deler sendes til mottakeren. Avsenderens offentlige nøkkel følger også med til verifisering.",[175,359,360,363],{},[157,361,362],{},"Verifisering:"," Mottakeren bruker avsenderens offentlige nøkkel til å dekryptere den digitale signaturen og hente ut den opprinnelige hashverdien. Deretter genererer mottakeren en ny hashverdi av meldingen som ble mottatt, og sammenligner den med den dekrypterte hashverdien. Stemmer de overens, bekrefter det at meldingen ikke er endret, og avsenderens identitet er verifisert.",[165,365,367],{"id":366},"hva-er-de-tre-funksjonene-til-asymmetrisk-kryptering","Hva er de tre funksjonene til asymmetrisk kryptering?",[153,369,370],{},"Asymmetrisk kryptering, også kjent som kryptografi med offentlig nøkkel, fyller flere viktige funksjoner når kommunikasjon og data skal sikres.",[258,372,373,378,383],{},[175,374,375],{},[157,376,377],{},"Kryptering og dekryptering",[175,379,380],{},[157,381,382],{},"Digitale signaturer",[175,384,385],{},[157,386,387],{},"Nøkkelutveksling",[165,389,391],{"id":390},"rsa","RSA",[153,393,394],{},"RSA, kort for Rivest-Shamir-Adleman, er et mye brukt kryptosystem med offentlig nøkkel for sikker dataoverføring. Det er oppkalt etter oppfinnerne Ronald Rivest, Adi Shamir og Leonard Adleman, som presenterte det i 1977.",[165,396,398],{"id":397},"diffie-hellman","Diffie-Hellman",[153,400,401],{},"Diffie-Hellman-nøkkelutveksling er en metode i kryptografien for å utveksle kryptografiske nøkler sikkert over en åpen kanal. Den ble utviklet av Whitfield Diffie og Martin Hellman i 1976. Hovedformålet med Diffie-Hellman-nøkkelutveksling er å la to parter i fellesskap etablere en delt hemmelig nøkkel på en sikker måte, som de kan bruke til å kryptere den videre kommunikasjonen.",[165,403,405],{"id":404},"digital-signature-algorithm-dsa","Digital Signature Algorithm (DSA)",[153,407,408],{},"Digital Signature Algorithm (DSA) er en kryptografisk algoritme med offentlig nøkkel som brukes til å generere og verifisere digitale signaturer. Den ble foreslått av National Institute of Standards and Technology (NIST) i 1991 som en del av Digital Signature Standard (DSS).",[410,411,413],"h4",{"id":412},"slik-fungerer-det","Slik fungerer det",[258,415,416,422,428],{},[175,417,418,421],{},[157,419,420],{},"Nøkkelgenerering:"," DSA genererer et nøkkelpar: en privat nøkkel til signering og en offentlig nøkkel til verifisering.",[175,423,424,427],{},[157,425,426],{},"Signering",": Avsenderen bruker sin private nøkkel til å opprette en digital signatur på en melding. Signaturen er unik for både meldingen og den private nøkkelen.",[175,429,430,433],{},[157,431,432],{},"Verifisering",": Mottakeren bruker avsenderens offentlige nøkkel til å verifisere at signaturen er ekte, og dermed også integriteten og opphavet til meldingen.",{"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},"no","h1-font-size","header-scepman-cryptography.png","/blog/heads/header-scepman-cryptography.png","Den sentrale utfordringen ved innrullering av sertifikater er hvordan du autentiserer enheten eller brukeren som ber om sertifikatet. Med sertifikatet bekrefter CA-en at sertifikateieren har bestemte egenskaper, og at den har kontrollert at de er ekte",{"menuItems":468},[469,471],{"href":470,"text":299},"#hashalgoritmer",{"href":472,"text":330},"#asymmetrisk-kryptografi",true,"/glossary/cryptography",{"title":142,"description":435},"glossary/cryptography","1gikXn6JKv-jUgyxVVot3sl4ImzDIPIJ2sYdhsTtJMk",{"id":479,"title":480,"author":143,"body":481,"cta":143,"description":485,"eventid":143,"extension":458,"hideInRecent":459,"layout":460,"meta":834,"moment":143,"navigation":473,"path":846,"seo":847,"stem":848,"tags":143,"webcast":459,"__hash__":849},"content_no/glossary/enrollment-methods.md","Innrulleringsmetoder",{"type":145,"value":482,"toc":821},[483,486,489,492,521,611,613,617,627,631,649,652,655,659,662,665,688,692,695,698,711,715,718,721,724,727,730,733,742,745,748,752,755,761,765,774,777,780,783,800,811,814,817],[153,484,485],{},"En kjerneegenskap ved protokoller for sertifikatinnrullering er derfor hvordan de autentiserer den som ber om sertifikatet. Avhengig av hva sertifikatet skal brukes til, er den ene eller den andre protokollen mest fordelaktig.",[153,487,488],{},"En annen viktig egenskap er hvor utbredt protokollen er i praksis. Innrulleringsmetoden eller protokollen må støttes både av CA-en og på klientsiden for det aktuelle bruksområdet.",[153,490,491],{},"De mest utbredte innrulleringsprotokollene er:",[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","Microsoft RPC/DCOM",[175,513,514],{},"Microsofts SOAP",[175,516,517],{},"Manuell innrullering på nettsiden til CA-en",[175,519,520],{},"Andre proprietære protokoller",[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],{},"Microsoft-proprietær DCOM og RPC",[533,539,540],{},"WS-Trust Enrollment Extension SOAP-innrullering",[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",{},"Spesifikasjoner",[553,557,558],{},"Microsoft OpenSpec1",[553,560,561],{},"Microsoft OpenSpec2",[553,563,564],{},"RFC 8555",[553,566,567],{},"Uformell, nå 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],{},"Implementering",[553,577,578],{},"Serverside: Active Directory CS Klientside: Windows",[553,580,581],{},"Serverside: ADCS, andre?  Klientside: Windows",[553,583,584],{},"Serverside: Let’s Encrypt Klientside: Mange",[553,586,587],{},"Mange server- og klientimplementeringer",[553,589,590],{},"Lite utbredt",[529,592,531,593,531,596,531,599,531,602,531,605,531,608,524],{},[553,594,595],{},"Autentisering",[553,597,598],{},"AD-autentisering",[553,600,601],{},"AD-autentisering\\* (formelt sett ligger ikke nødvendigvis brukernavn og passord i AD)",[553,603,604],{},"DNS-autentisering",[553,606,607],{},"«SCEP Challenge»",[553,609,610],{},"CBA eller HTTP Basic-/Digest-autentisering",[148,612,499],{"id":498},[165,614,616],{"id":615},"historikk-og-spesifikasjon","Historikk og spesifikasjon",[153,618,619,620,626],{},"Cisco var først ute med å finne opp Simple Certificate Enrollment Protocol (SCEP). Selv om det ikke fantes noen standard den gangen, ble protokollen svært utbredt i MDM-systemer. Cisco gikk til og med videre og utformet en etterfølger, Enrollment over Secure Transport (EST), som skulle erstatte SCEP. EST ble derfor en offentlig standard i RFC 7030 lenge før SCEP, som først ble standardisert i ",[242,621,625],{"href":622,"rel":623},"https://www.rfc-editor.org/rfc/rfc8894.html",[624],"nofollow","RFC 8894"," mye senere, da den allerede var de facto-standarden for sertifikatinnrullering i MDM-systemer.",[165,628,630],{"id":629},"teknologi","Teknologi",[153,632,633,634,638,639,643,644,648],{},"SCEP er HTTP-basert. En SCEP-forespørsel er en kryptert og signert ",[242,635,637],{"href":636},"important-data-formats#pkcs7","PKCS#7"," som sendes via en GET- eller POST-forespørsel til SCEP-tjenesten. Tjenesten svarer med et SCEP-svar, som igjen er en kryptert og signert PKCS#7. Forespørselen inneholder en ",[242,640,642],{"href":641},"important-data-formats#pkcs10","PKCS#10","-sertifikatsigneringsforespørsel, og svaret inneholder det utstedte ",[242,645,647],{"href":646},"important-data-formats#x509","X.509-sertifikatet",".",[165,650,595],{"id":651},"autentisering",[153,653,654],{},"PKCS#10-forespørselen inneholder en «SCEP Challenge» som autentiserer og autoriserer signeringsforespørselen gjennom en metode utenfor kanalen, avhengig av den konkrete SCEP-tjenesten. Det finnes tre typer SCEP-challenger i praktisk bruk i dag:",[410,656,658],{"id":657},"statisk-scep-challenge","Statisk SCEP Challenge",[153,660,661],{},"Den enkleste muligheten er en statisk passfrase. Hvis SCEP-challengen i PKCS#10 stemmer med en forhåndsdefinert verdi som er lagret på SCEP-tjenesten, blir sertifikatet utstedt, ellers blir forespørselen avvist. Problemet med denne metoden er at det knapt er mulig å kontrollere om egenskapene det bes om i sertifikatet, faktisk passer til den som ber om det. Det finnes til og med en CVE for dette problemet.",[153,663,664],{},"Disse metodene kan deles ytterligere inn:",[258,666,667,675,682],{},[175,668,669,670,674],{},"Ved en ",[671,672,673],"em",{},"direkte"," SCEP-innrullering kommuniserer enheten som sertifikatet skal innrulleres til, direkte med SCEP-tjenesten. For eksempel kan et MDM-system be en Android-telefon om å gjøre en SCEP-innrullering med SCEP-challengen «SecurePassword». Android-telefonen genererer en CSR, forhåpentlig med riktige verdier, og legger til «SecurePassword» som SCEP-challenge. Deretter sender den CSR-en til SCEP-tjenesten og får det utstedte sertifikatet i retur.",[175,676,677,678,681],{},"En ",[671,679,680],{},"transparent SCEP-proxy"," fungerer akkurat som en omvendt HTTP-proxy. Fordi SCEP er kryptert og signert, kan den ikke se inn i SCEP-forespørslene eller SCEP-svarene, og heller ikke endre dem, men den kan styre hvem som får innrullere sertifikater og når, ut fra nettverksgrenser.",[175,683,677,684,687],{},[671,685,686],{},"protokolladapter-SCEP-proxy"," er et system som ber om sertifikater via SCEP på vegne av et annet system. Et MDM-system som JAMF kan for eksempel be en SCEP-tjeneste om et sertifikat på vegne av en iPhone. Når systemet har sertifikatet og den private nøkkelen, kan det rulle ut sertifikatet gjennom en annen protokoll. Slik er det bare MDM-systemet som har tilgang til SCEP-challengen, og det kan i tillegg styre innholdet i sertifikatet.",[410,689,691],{"id":690},"dynamisk-scep-challenge","Dynamisk SCEP Challenge",[153,693,694],{},"Her er hver SCEP-challenge bare gyldig for én enkelt sertifikatforespørsel. Dermed kan SCEP-tjenesten identifisere SCEP-forespørselen og kontrollere at sertifikategenskapene det bes om, stemmer med det som er tillatt for nettopp den forespørselen.",[153,696,697],{},"I praksis brukes det stort sett to måter for at et MDM-system og en SCEP-CA skal bli enige om en SCEP-challenge for en forespørsel:",[258,699,700,708],{},[175,701,702,703],{},"MDM-systemet ber SCEP-tjenesten om en engangskode for en SCEP-forespørsel når det trenger en.\n",[258,704,705],{},[175,706,707],{},"Et eksempel er Microsoft NDES. NDES har en egen administrasjonsside som autentiseres med AD-legitimasjon. Hver gang siden åpnes, opprettes og vises en ny engangskode som kan brukes til én enkelt SCEP-forespørsel. Brukt på denne måten kontrollerer NDES likevel ingen egenskaper ved sertifikatet, siden engangskoden er generisk.",[175,709,710],{},"MDM-systemet genererer en engangskode når det ber et administrert system om å be om et sertifikat via SCEP. Når SCEP-forespørselen kommer til SCEP-tjenesten, må tjenesten hente engangskoden fra MDM-systemet, vanligvis med en webhook, og kontrollere at den stemmer med SCEP-challengen i forespørselen. Det finnes ingen standard for denne protokollen, så MDM-systemet og SCEP-tjenesten må bli enige om et format, og det avhenger av implementeringen om egenskaper ved forespørselen i det hele tatt kontrolleres.",[410,712,714],{"id":713},"signerte-metadata","Signerte metadata",[153,716,717],{},"Det er i praksis ingen lengdebegrensning på SCEP-challengen. Den trenger derfor ikke å være en passfrase et menneske kan lese, den kan like gjerne være en BLOB.",[153,719,720],{},"Intune bruker en signert og kryptert XML som SCEP-challenge. Intune oppretter denne XML-en på serversiden og sender den til en klientenhet når enheten skal innrullere et sertifikat og opprette SCEP-forespørselen.",[153,722,723],{},"SCEP-tjenesten må sende hele PKCS#10-forespørselen til en Intune SCEP Challenge-tjeneste. SCEP Challenge-tjenesten har den private nøkkelen til å dekryptere XML-en og den offentlige nøkkelen til å kontrollere at den ble opprettet av en ekte Intune-tjeneste.",[153,725,726],{},"XML-en inneholder metadata om forespørselen, blant annet hvordan subjektet skal se ut. Dette utledes på den ene siden av SCEP-konfigurasjonsprofilen og på den andre siden av de konkrete objektdataene for brukeren eller enheten som sertifikatet skal utstedes til.",[153,728,729],{},"SCEP-konfigurasjonsprofilen kan for eksempel angi CN={{DeviceId}} som subjekt. Når enheten med ID-en xyz ber om et sertifikat, sier XML-en at subjektet skal være CN=xyz. SCEP Challenge-tjenesten sammenligner så opplysningene fra XML-en med subjektet i PKCS#10-forespørselen. Valideringen mislykkes hvis subjektene er forskjellige, og den lykkes hvis dette og de andre egenskapene stemmer.",[153,731,732],{},"SCEP-tjenesten utsteder bare sertifikatet hvis valideringen lykkes.",[153,734,735,736,741],{},"Microsoft har ",[242,737,740],{"href":738,"rel":739},"https://learn.microsoft.com/en-us/mem/intune/protect/certificate-authority-add-scep-overview#overview",[624],"en artikkel"," som forklarer denne verifiseringen.",[153,743,744],{},"Microsoft NDES støtter dette med en ekstra NDES-policymodul, mens andre SCEP-CA-er kan ha eller mangle innebygd støtte for det.",[148,746,511],{"id":747},"microsoft-rpcdcom",[165,749,751],{"id":750},"historikk","Historikk",[153,753,754],{},"Microsoft Active Directory Certificate Services (ADCS), av og til bare kalt «Microsoft CA», er programvaren for sertifikatmyndighet som er innebygd i Windows Server. Programvaren ble opprinnelig utviklet mot slutten av forrige årtusen og fikk stadig noen tillegg de neste ti til femten årene.",[153,756,757,758,760],{},"Et alternativ er Microsofts SOAP eller ",[242,759,499],{"href":498},", som Microsoft kaller henholdsvis Web Enrollment og NDES.",[165,762,764],{"id":763},"spesifikasjon-og-utbredelse","Spesifikasjon og utbredelse",[153,766,767,768,773],{},"Vi kjenner ikke til andre CA-systemer som implementerer denne protokollen, selv om Microsoft i mellomtiden har publisert ",[242,769,772],{"href":770,"rel":771},"https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cersod/dd034cb3-99fc-4c10-92c8-1fbeb4788183",[624],"spesifikasjonen i Microsoft OpenSpec",". På klientsiden har Windows innebygd støtte for protokollen, andre plattformer støttes ikke.",[165,775,630],{"id":776},"teknologi-1",[153,778,779],{},"Hovedmetoden for innrullering er en proprietær protokoll basert på RPC eller DCOM.",[153,781,782],{},"Automatisk innrullering bruker også denne protokollen. For at automatisk innrullering skal fungere, trenger du",[172,784,785,788,791,794,797],{},[175,786,787],{},"en domenetilknyttet enhet.",[175,789,790],{},"Gruppepolicy må aktivere automatisk innrullering,",[175,792,793],{},"en Enterprise CA (i motsetning til frittstående)",[175,795,796],{},"som innrullerer en sertifikatmal der",[175,798,799],{},"brukeren eller enheten har tillatelsene for innrullering og automatisk innrullering.",[153,801,802,803,807,808,648],{},"Standardintervallet for å se etter automatiske innrulleringer er 8 timer, men det kan tvinges fram med ",[804,805,806],"code",{},"certutil -pulse"," eller ofte bedre med ",[804,809,810],{},"gpupdate -force",[165,812,595],{"id":813},"autentisering-1",[153,815,816],{},"Denne protokollen bruker autentiseringsprotokollene som er innebygd i Active Directory, det vil si at brukere og datamaskiner autentiserer seg med AD-legitimasjonen sin.",[818,819,820],"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":822},[823,828],{"id":498,"depth":436,"text":499,"children":824},[825,826,827],{"id":615,"depth":441,"text":616},{"id":629,"depth":441,"text":630},{"id":651,"depth":441,"text":595},{"id":747,"depth":436,"text":511,"children":829},[830,831,832,833],{"id":750,"depth":441,"text":751},{"id":763,"depth":441,"text":764},{"id":776,"depth":441,"text":630},{"id":813,"depth":441,"text":595},{"lang":462,"seoTitle":835,"titleClass":463,"socialimg":836,"blogtitlepic":837,"customExcerpt":838,"keywords":839,"asideNav":840,"maxContent":473},"Metoder for sertifikatinnrullering: SCEP, ACME, EST og Microsoft RPC","/blog/heads/header-scepman-enrollment-methods.png","header-scepman-enrollment-methods.png","Lær hvordan innrullering av sertifikater fungerer med SCEP, ACME, EST, Microsoft RPC og manuelle metoder. Sammenlign innrulleringsprotokoller for PKI og sikker utstedelse av sertifikater.","metoder for sertifikatinnrullering, SCEP, ACME, EST, Microsoft RPC, protokoll for sertifikatinnrullering, sertifikatinnrullering i PKI, enrollment over secure transport, Simple Certificate Enrollment Protocol, Automatic Certificate Management Environment, Microsoft-sertifikatinnrullering",{"menuItems":841},[842,844],{"href":843,"text":499},"#scep",{"href":845,"text":511},"#microsoft-rpcdcom","/glossary/enrollment-methods",{"title":480,"description":485},"glossary/enrollment-methods","0fLckwgDxdalc5CIz65LcRm2gLmIynah5KHyugj8Kak",{"id":851,"title":852,"author":143,"body":853,"cta":143,"description":435,"eventid":143,"extension":458,"hideInRecent":459,"layout":460,"meta":1087,"moment":143,"navigation":473,"path":1105,"seo":1106,"stem":1107,"tags":143,"webcast":459,"__hash__":1108},"content_no/glossary/important-data-formats.md","Viktige dataformater",{"type":145,"value":854,"toc":1070},[855,859,878,885,888,892,896,899,902,905,909,912,916,919,922,930,933,937,945,948,951,954,965,969,982,986,989,992,995,998,1006,1010,1013,1016,1019,1030,1034,1037,1041,1049,1053,1061,1064],[148,856,858],{"id":857},"x509","X.509",[153,860,861,862,865,866,871,872,877],{},"X.509 er ",[671,863,864],{},"selve"," standarden for digitale sertifikater. Det fantes tidligere konkurrenter som ",[242,867,870],{"href":868,"rel":869},"https://www.rfc-editor.org/rfc/rfc4880",[624],"OpenPGP",", men de brukes langt sjeldnere i dag. Men vent litt: X.509 er egentlig ikke den riktige standarden. X.509 er faktisk en ITU-T-standard, mens definisjonene som virkelig betyr noe, er en del av ",[242,873,876],{"href":874,"rel":875},"https://www.rfc-editor.org/rfc/rfc5280",[624],"RFC 5280",", altså en standard fra IETF og ikke fra ITU-T. RFC-en definerer «PKI-profilen for internett» basert på X.509, og det er den eneste profilen som har reell betydning i praksis.",[153,879,880,881,884],{},"Et digitalt sertifikat bruker asymmetrisk kryptografi og særlig digitale signaturer. Det vanligste bruksområdet for digitale sertifikater i dag er serverautentisering. Alle har brukt dem allerede, sannsynligvis uten å vite at det dreide seg om et X.509-sertifikat: Hver gang du åpner et HTTP",[157,882,883],{},"S","-nettsted, oppretter nettleseren en TLS-forbindelse til webserveren. Webserveren bruker et X.509-sertifikat til å bevise hvem den er. Når folk går inn på nettsiden til banken sin for å overføre penger fra kontoen, vil de være sikre på at de faktisk kommuniserer med banken. Angripere kan forsøke å utgi seg for å være banknettstedet, lese brukerens passord og engangskode og så overføre pengene til en konto de selv kontrollerer. HTTPS bidrar til å hindre dette, fordi angriperne ikke har X.509-sertifikatet til bankens webserver. Når nettleseren sier at du besøker et bestemt domene og at forbindelsen er HTTPS, sørger sertifikatet for at du virkelig er koblet til en webserver som tilhører noen som eier det domenet.",[153,886,887],{},"Hvordan får sertifikatet dette til? Sertifikatet inneholder noen metadata, den offentlige nøkkelen i et kryptografisk nøkkelpar og en signatur fra en sertifikatmyndighet. La oss gå gjennom de tre delene:",[165,889,891],{"id":890},"innholdet-i-et-x509-sertifikat","Innholdet i et X.509-sertifikat",[410,893,895],{"id":894},"metadata","Metadata",[153,897,898],{},"Metadataene i X.509-sertifikatet angir blant annet hvilket tidsrom det er gyldig i, hva sertifikatet skal brukes til, og hvem det ble utstedt til. For et TLS-serversertifikat inneholder de særlig domenet til webserveren. Nettleseren sammenligner domenet den forsøkte å åpne, med domenet i sertifikatet. Stemmer de ikke overens, går ikke nettleseren videre, men viser en advarsel. Har sertifikatet utløpt, viser den også en advarsel.",[153,900,901],{},"Merkelig nok viste nettlesere ofte ingen advarsel hvis du åpnet et HTTP-nettsted uten TLS, selv om det er enda mindre sikkert. Åpnet du en webserver med et ugyldig X.509-sertifikat, kunne det rett og slett være en feilkonfigurasjon, og du kunne faktisk være beskyttet mot angripere som spionerer på forbindelsen, mens HTTP-forbindelsen ikke gir noen beskyttelse i det hele tatt.",[153,903,904],{},"Det finnes likevel framgang på dette området, for eksempel Certificate Pinning. Men det er et avansert tema, så la oss se på de to andre tingene som finnes i et X.509-sertifikat.",[410,906,908],{"id":907},"offentlig-nøkkel","Offentlig nøkkel",[153,910,911],{},"Sertifikatet inneholder den offentlige delen av et asymmetrisk nøkkelpar. Kryptografien gjør at webserveren, eller mer generelt sertifikatinnehaveren i andre bruksområder, kan bevise at den også har den private delen av nøkkelparet uten å avsløre den for klienten som kobler seg til, eller for andre. Dermed kan klienten være sikker på at webserveren faktisk eier sertifikatet og ikke bare har kopiert det. Å kopiere selve sertifikatet er ganske enkelt, siden webserveren sender en kopi av det til alle som forsøker å koble seg til serveren. Å stjele den private nøkkelen er vanskelig eller umulig, siden den aldri forlater webserveren. Det finnes ulike metoder for å gjøre tyveri av den private nøkkelen vanskeligere, for eksempel HSM-er og TPM-er.",[410,913,915],{"id":914},"signatur-fra-en-sertifikatmyndighet","Signatur fra en sertifikatmyndighet",[153,917,918],{},"Metadataene lar klienten kontrollere at sertifikatet passer til det aktuelle bruksområdet. Den offentlige nøkkelen viser at motparten faktisk eier sertifikatet. Men en angriper kan jo bare opprette et nytt nøkkelpar og et nytt sertifikat som også oppfyller disse to kriteriene. Hvordan skal en klient vite at sertifikatet er til å stole på?",[153,920,921],{},"Sertifikatet inneholder en kryptografisk signatur fra et annet nøkkelpar som hører til et sertifikat for en sertifikatmyndighet (CA). CA-sertifikatet kan kontrolleres på samme måte og er også signert av et sertifikat. Klienten kan følge denne tillitskjeden fra det såkalte bladsertifikatet helt opp til rot-CA-sertifikatet, som den kjenner igjen på at det er selvsignert, altså at signaturen i sertifikatet kommer fra sertifikatets eget nøkkelpar. Vanligvis er dette bare ett eller to trinn, så det er bare ett eller to CA-sertifikater involvert.",[153,923,924,925,929],{},"CA-er må kontrollere nøye at metadataene er riktige når de ",[242,926,928],{"href":927},"enrollment-methods/","utsteder et sertifikat",". Vil du for eksempel ha et TLS-serversertifikat for ditt eget domene, må du bevise overfor CA-en at du virkelig eier det. Hvor grundig denne kontrollen er, avgjør om du får et vanlig sertifikat eller et Extended Validation-sertifikat (EV).",[153,931,932],{},"Hver nettleser og hvert operativsystem leveres med en liste over forhåndsdefinerte betrodde rot-CA-er. Brukere og administratorer kan legge til flere betrodde rot-CA-er. Noen rot-CA-er er bare betrodd for bestemte formål, andre har en mer generell tillit. Klienten kontrollerer om tillitskjeden ender i en betrodd rot-CA. Gjør den det, og alle sertifikatene i tillitskjeden fortsatt er gyldige og metadataene sier at de brukes i tråd med formålet sitt, er bladsertifikatet til webserveren betrodd, og forbindelsen opprettes.",[165,934,936],{"id":935},"gyldigheten-til-x509-sertifikater","Gyldigheten til X.509-sertifikater",[153,938,939,940,944],{},"X.509-sertifikater handler helt og holdent om tillit som må etableres. Som forklart er ett kriterium for tillit at et sertifikat må kjede seg opp til en betrodd rot-CA. Et annet er at det er innenfor gyldighetsperioden sin. Vanligvis betyr det at det ikke er utløpt, men et sertifikat kan også være ennå ikke gyldig, som regel på grunn av tekniske feil. Og det finnes ett kriterium til: CA-en som utstedte sertifikatet, må ikke ha tilbakekalt det. Fordi dette er et tema for seg, har vi en ",[242,941,943],{"href":942},"other-stuff/certificate-lifecycle-management","egen artikkel"," om det.",[148,946,637],{"id":947},"pkcs7",[153,949,950],{},"PKCS#7 er den sveitsiske lommekniven blant kryptografiske dataformater og kan inneholde omtrent hva som helst: krypterte meldinger, signerte meldinger, signerte og krypterte meldinger, sertifikater og private nøkler",[153,952,953],{},"Dette er samtidig den største ulempen med formatet. Får en applikasjon eller en bruker en PKCS#7, er det ikke uten videre klart hva som skal gjøres med den. Her er noen viktige bruksområder:",[172,955,956,959,962],{},[175,957,958],{},"S/MIME-meldinger er i bunn og grunn e-poster med PKCS#7-innhold eller PKCS#7-vedlegg.",[175,960,961],{},"SCEP-forespørsler og SCEP-svar er i praksis begge signerte PKCS#7-meldinger.",[175,963,964],{},"EST-svar er CMS-meldinger.",[165,966,968],{"id":967},"koding","Koding",[153,970,971,972,976,977,981],{},"Vanlige filendelser er .p7b (",[242,973,975],{"href":974},"asn.1-and-pem#der-encoding","DER-kodet","), .p7s (en signert melding eller en meldingssignatur) og .p7m (en signert og/eller kryptert melding). ",[242,978,980],{"href":979},"asn.1-and-pem#pem-encoding","PEM-kodingen"," med etiketten «PKCS7» er også definert, men brukes sjelden.",[165,983,985],{"id":984},"verktøy","Verktøy",[153,987,988],{},"I Windows kan du åpne PKCS#7-meldinger med et dobbeltklikk, og Crypto-shell-utvidelsene viser dem for deg. Som regel kan du likevel bare hente ut sertifikater og de private nøklene deres, ikke innholdet i meldingene.",[153,990,991],{},"Du kan konvertere disse filene til andre formater med verktøy som OpenSSL.",[148,993,642],{"id":994},"pkcs10",[153,996,997],{},"En sertifikatsigneringsforespørsel (CSR) slik den er definert i PKCS#10, er en fil som beskriver et sertifikat du gjerne vil få fra en sertifikatmyndighet (CA). Den har en struktur som ligner på et X.509-sertifikat, men den mangler signaturen fra en CA. I stedet inneholder den signaturen til den som ber om sertifikatet. Det er fortsatt et annet format, så den er ikke det samme som et selvsignert sertifikat.",[153,999,1000,1001,648],{},"Den kan være binært DER-kodet eller PEM-kodet ",[242,1002,1005],{"href":1003,"rel":1004},"https://datatracker.ietf.org/doc/html/rfc7468#section-7",[624],"med etiketten «CERTIFICATE REQUEST»",[148,1007,1009],{"id":1008},"pkcs12","PKCS#12",[153,1011,1012],{},"PKCS#12 er også kjent som PFX, særlig i Windows-miljøer. Vanlige filendelser er derfor .pfx og .p12. Formatet inneholder X.509-sertifikater og nesten alltid tilhørende private nøkler, selv om det strengt tatt ikke er teknisk påkrevd.",[153,1014,1015],{},"Data i en PKCS#12-fil er vanligvis kryptert med passord. Ofte er bare den private nøkkelen kryptert, så du kan hente ut sertifikatene uten å kjenne passordene hvis applikasjonen din tillater det, og det gjør de fleste ikke. PKCS#12 er den vanligste måten å lagre et sertifikat og den private nøkkelen til det i en fil på i Windows-miljøer. I Linux-miljøer er PEM-kodede PKCS#8-filer vanligere.",[153,1017,1018],{},"Fordi standarden gir mange valg for hvordan sertifikater og private nøkler kan lagres i nøstede «safebags», har PKCS#12-filer visse kompatibilitetsproblemer, blant annet:",[172,1020,1021,1024,1027],{},[175,1022,1023],{},"Windows er beryktet for å knytte private nøkler i PKCS#12 til alle sertifikatene som hentes ut av filen, ikke bare til det sertifikatet nøkkelen hører til. Inneholder PKCS#12-filen en sertifikatkjede, kan Windows vise at den har den private nøkkelen til CA-sertifikatet.",[175,1025,1026],{},"På macOS kan du ikke importere PKCS#12-filer hvis de kryptografiske algoritmene er for nye.",[175,1028,1029],{},"Det kan være nødvendig å kryptere sertifikatene i en PKCS#12-fil for at mottakerapplikasjonene skal kunne hente dem ut. Men noen støtter bare svært gamle og svake algoritmer, og det er vanligvis ikke noe problem, siden informasjonen uansett er offentlig. OpenSSL 3.x støtter derimot ikke disse gamle og sårbare algoritmene og nekter å åpne PKCS#12-filen.",[148,1031,1033],{"id":1032},"asn1-og-pem","ASN.1 og PEM",[153,1035,1036],{},"Abstract Syntax Notation One (ASN.1) er et språk som brukes til å beskrive datastrukturer. Det finnes noen forhåndsdefinerte grunnleggende datatyper, for eksempel heltall eller sekvenser, og den som lager en protokoll eller et filformat, kan deretter definere egne datatyper med utgangspunkt i de grunnleggende.",[165,1038,1040],{"id":1039},"der-koding","DER-koding",[153,1042,1043,1048],{},[242,1044,1047],{"href":1045,"rel":1046},"https://www.itu.int/rec/T-REC-X.680/",[624],"ITU-T-standarden X.680"," definerer ulike kodinger for data som er angitt som ASN.1. For X.509-relaterte data er DER den viktigste kodingen, fordi det bare finnes én måte å kode en type på. En hashverdi av den binære DER-representasjonen av typen vil derfor alltid ha samme verdi, noe som er viktig for eksempel ved signering av ASN.1-kodede data.",[165,1050,1052],{"id":1051},"pem-koding","PEM-koding",[153,1054,1055,1056,1060],{},"For mange, men ikke alle, X.509-relaterte filtyper kan du enten lagre filen binært i DER-koding eller legge en ekstra ",[242,1057,1052],{"href":1058,"rel":1059},"https://datatracker.ietf.org/doc/html/rfc7468",[624]," oppå DER-kodingen. PEM bruker bare ASCII-tegn og kan derfor enkelt kopieres og limes inn via utklippstavlen, eller sendes på e-post, slik det var relevant for noen tiår siden.",[165,1062,985],{"id":1063},"verktøy-1",[153,1065,1066,1067,648],{},"Har du en ASN.1-kodet fil og enten ikke vet hvilken type det er, eller mangler en applikasjon som håndterer nettopp den typen, kan du likevel dekode den rå ASN.1-strukturen og se hva den inneholder. I Windows kan det innebygde verktøyet certutil gjøre dette med kommandoen ",[804,1068,1069],{},"certutil -decode",{"title":435,"searchDepth":436,"depth":436,"links":1071},[1072,1076,1080,1081,1082],{"id":857,"depth":436,"text":858,"children":1073},[1074,1075],{"id":890,"depth":441,"text":891},{"id":935,"depth":441,"text":936},{"id":947,"depth":436,"text":637,"children":1077},[1078,1079],{"id":967,"depth":441,"text":968},{"id":984,"depth":441,"text":985},{"id":994,"depth":436,"text":642},{"id":1008,"depth":436,"text":1009},{"id":1032,"depth":436,"text":1033,"children":1083},[1084,1085,1086],{"id":1039,"depth":441,"text":1040},{"id":1051,"depth":441,"text":1052},{"id":1063,"depth":441,"text":985},{"lang":462,"seoTitle":1088,"titleClass":463,"blogtitlepic":1089,"socialimg":1090,"customExcerpt":1091,"keywords":1092,"asideNav":1093,"maxContent":473},"Viktige dataformater: X.509, PKCS, ASN.1 og PEM forklart","header-scepman-important-data-formats.png","/blog/heads/header-scepman-important-data-formats.png","Bli kjent med de viktigste kryptografi- og sertifikatformatene, blant andre X.509, PKCS 7, PKCS 10, PKCS 12, ASN.1 og PEM.","viktige dataformater, X.509-sertifikat, PKCS-formater, PKCS 7, PKCS 10, PKCS 12, ASN.1, PEM-format, digitale sertifikater, public key infrastructure, PKI-formater",{"menuItems":1094},[1095,1097,1099,1101,1103],{"href":1096,"text":858},"#x509",{"href":1098,"text":637},"#pkcs7",{"href":1100,"text":642},"#pkcs10",{"href":1102,"text":1009},"#pkcs12",{"href":1104,"text":1033},"#asn1-og-pem","/glossary/important-data-formats",{"title":852,"description":435},"glossary/important-data-formats","tSfRV21GTa94wDNyGHUeUZn7yV7tXOi3Anv234FMi_o",{"id":1110,"title":1111,"author":143,"body":1112,"cta":143,"description":435,"eventid":143,"extension":458,"hideInRecent":459,"layout":460,"meta":1335,"moment":143,"navigation":473,"path":1341,"seo":1342,"stem":1343,"tags":143,"webcast":459,"__hash__":1344},"content_no/glossary/public-key-infrastructure.md","Public Key Infrastructure",{"type":145,"value":1113,"toc":1324},[1114,1118,1126,1129,1161,1165,1168,1172,1175,1205,1208,1212,1215,1235,1238,1242,1249,1263,1268,1282,1286,1291,1304,1309,1321],[148,1115,1117],{"id":1116},"slik-etableres-tillit","Slik etableres tillit",[165,1119,1121,1122,1125],{"id":1120},"hvordan-viser-en-klient-at-den-stoler-på-en-bestemt-rot-ca","Hvordan ",[157,1123,1124],{},"viser"," en klient at den stoler på en bestemt rot-CA?",[153,1127,1128],{},"En klient viser at den stoler på en bestemt rotsertifikatmyndighet (CA) gjennom en prosess som bygger på sertifikatets tillitskjede. Slik fungerer det:",[172,1130,1131,1137,1143,1149,1155],{},[175,1132,1133,1136],{},[157,1134,1135],{},"Forhåndsinstallerte rotsertifikater:"," De fleste operativsystemer og nettlesere leveres med et sett forhåndsinstallerte rotsertifikater fra betrodde CA-er. Disse rotsertifikatene ligger i et lager for betrodde rotsertifikater.",[175,1138,1139,1142],{},[157,1140,1141],{},"Validering av sertifikatet:"," Når en klient kobler seg til en server, for eksempel ved å besøke et nettsted, legger serveren fram TLS-sertifikatet sitt. Dette sertifikatet er vanligvis signert av en mellomliggende CA, som i sin tur er signert av en rot-CA.",[175,1144,1145,1148],{},[157,1146,1147],{},"Verifisering av tillitskjeden:"," Klienten verifiserer tillitskjeden ved å kontrollere om sertifikatet som legges fram, er signert av en betrodd rot-CA. Den kontrollerer også om de mellomliggende CA-ene i kjeden er betrodde.",[175,1150,1151,1154],{},[157,1152,1153],{},"Digitale signaturer:"," Hvert sertifikat i kjeden er digitalt signert av CA-en over seg. Klienten bruker den offentlige nøkkelen til CA-en for å verifisere disse signaturene, og sikrer dermed at sertifikatene ikke er manipulert.",[175,1156,1157,1160],{},[157,1158,1159],{},"Tillitsbeslutning:"," Hvis hele tillitskjeden er gyldig og fører tilbake til en betrodd rot-CA, stoler klienten på serverens sertifikat. Da kan den sikre kommunikasjonen fortsette.",[165,1162,1164],{"id":1163},"hva-er-fordelen-med-mellomliggende-ca-er-framfor-én-enkelt-rot-ca","Hva er fordelen med mellomliggende CA-er framfor én enkelt rot-CA?",[153,1166,1167],{},"For infrastruktur-PKI-er kan én enkelt rot faktisk være en fordel.",[165,1169,1171],{"id":1170},"hvordan-får-en-mellomliggende-ca-sertifikatet-sitt","Hvordan får en mellomliggende CA sertifikatet sitt?",[153,1173,1174],{},"En mellomliggende sertifikatmyndighet (CA) får sertifikatet sitt gjennom en prosess som kalles kryssignering fra en rot-CA. Slik fungerer det:",[258,1176,1177,1183,1189,1194,1199],{},[175,1178,1179,1182],{},[157,1180,1181],{},"Certificate Signing Request (CSR):"," Virksomheten som vil sette opp en mellomliggende CA, genererer en CSR. Denne CSR-en inneholder den offentlige nøkkelen og identitetsopplysningene til den mellomliggende CA-en.",[175,1184,1185,1188],{},[157,1186,1187],{},"Innsending til rot-CA-en:"," CSR-en sendes inn til en betrodd rot-CA.",[175,1190,1191,1193],{},[157,1192,362],{}," Rot-CA-en verifiserer identiteten og legitimiteten til virksomheten som ber om det mellomliggende sertifikatet.",[175,1195,1196,1198],{},[157,1197,350],{}," Når verifiseringen er gjort, bruker rot-CA-en sin private nøkkel til å signere CSR-en, og det mellomliggende sertifikatet blir til. Dette signerte sertifikatet knytter den mellomliggende CA-en til rot-CA-en og etablerer en tillitskjede.",[175,1200,1201,1204],{},[157,1202,1203],{},"Utstedelse:"," Rot-CA-en utsteder det signerte mellomliggende sertifikatet til virksomheten som ba om det, og virksomheten kan deretter bruke det til å signere sluttsertifikater, for eksempel TLS-sertifikater for nettsteder.",[153,1206,1207],{},"Denne prosessen sørger for at den mellomliggende CA-en er betrodd i kraft av tilknytningen til rot-CA-en, som nettlesere og operativsystemer allerede stoler på.",[165,1209,1211],{"id":1210},"hva-er-en-sertifikatkjede-og-hvordan-fungerer-den","Hva er en sertifikatkjede, og hvordan fungerer den?",[153,1213,1214],{},"En sertifikatkjede, også kalt tillitskjede, er en rekke sertifikater som sikrer at et digitalt sertifikat er ekte og til å stole på. Slik fungerer det:",[172,1216,1217,1223,1229],{},[175,1218,1219,1222],{},[157,1220,1221],{},"Verifiseringsprosess:"," Når en klient, for eksempel en nettleser, kobler seg til en server, legger serveren fram sluttsertifikatet sitt. Klienten går deretter gjennom sertifikatkjeden for å kontrollere at hvert sertifikat er signert av det neste sertifikatet i kjeden, helt opp til rotsertifikatet.",[175,1224,1225,1228],{},[157,1226,1227],{},"Tillitskjede:"," Hvert sertifikat i kjeden verifiseres med den offentlige nøkkelen til sertifikatet over seg. Slik fortsetter det fram til rotsertifikatet, som klienten allerede stoler på.",[175,1230,1231,1234],{},[157,1232,1233],{},"Etablering av tillit:"," Hvis hele kjeden er gyldig og fører tilbake til et betrodd rotsertifikat, stoler klienten på sluttsertifikatet, og den sikre kommunikasjonen kan fortsette.",[153,1236,1237],{},"Dette systemet sikrer at sluttsertifikatet er legitimt og utstedt av en betrodd myndighet, og opprettholder dermed integriteten og sikkerheten i digital kommunikasjon.",[165,1239,1241],{"id":1240},"hvilket-problem-skal-utvidelsen-basic-constraints-løse","Hvilket problem skal utvidelsen Basic Constraints løse?",[153,1243,1244,1245,1248],{},"Utvidelsen ",[157,1246,1247],{},"Basic Constraints"," i et digitalt sertifikat løser problemet med å skille mellom ulike sertifikattyper og rollene de har i en Public Key Infrastructure (PKI). Slik fungerer det:",[172,1250,1251,1257],{},[175,1252,1253,1256],{},[157,1254,1255],{},"Identifisering av sertifikatmyndighet (CA):"," Den angir om et sertifikat er et CA-sertifikat eller et sluttsertifikat. Dette skillet er avgjørende, fordi CA-sertifikater kan utstede andre sertifikater, mens sluttsertifikater ikke kan det.",[175,1258,1259,1262],{},[157,1260,1261],{},"Begrensning av kjedelengde:"," Den kan begrense hvor mange mellomliggende CA-er som kan finnes under denne CA-en i sertifikatkjeden. Det bidrar til å hindre unødig lange sertifikatkjeder, som kan være ineffektive og potensielt usikre.",[153,1264,1265],{},[157,1266,1267],{},"Problemer som løses:",[172,1269,1270,1276],{},[175,1271,1272,1275],{},[157,1273,1274],{},"Hindrer uautorisert utstedelse av sertifikater:"," Ved å merke tydelig hvilke sertifikater som kan opptre som CA-er, hindrer utvidelsen at sluttsertifikater utsteder andre sertifikater, og bevarer dermed integriteten i PKI-en.",[175,1277,1278,1281],{},[157,1279,1280],{},"Styrer lengden på sertifikatkjeden:"," Ved å begrense kjedelengden sikrer utvidelsen at sertifikatkjeden forblir håndterbar og sikker, og forebygger potensielle sårbarheter knyttet til lange kjeder",[165,1283,1285],{"id":1284},"hvilke-mekanismer-bruker-den-til-å-løse-problemene"," Hvilke mekanismer bruker den til å løse problemene?",[153,1287,1244,1288,1290],{},[157,1289,1247],{}," i et digitalt sertifikat bruker følgende mekanismer for å løse problemene med å skille CA-sertifikater fra sluttsertifikater og styre lengden på sertifikatkjeden:",[172,1292,1293,1299],{},[175,1294,1295,1298],{},[157,1296,1297],{},"CA-flagget:"," Dette flagget angir om sertifikatet er et sertifikatmyndighetssertifikat (CA) eller et sluttsertifikat. Er flagget satt til TRUE, kan sertifikatet brukes til å signere andre sertifikater, og det er dermed et CA-sertifikat. Er det satt til FALSE, er det et sluttsertifikat som ikke kan utstede andre sertifikater.",[175,1300,1301,1303],{},[157,1302,1261],{}," Denne angir det høyeste antallet mellomliggende sertifikater som ikke er selvutstedte, og som kan følge etter dette sertifikatet i en gyldig sertifiseringssti. Ved å sette denne begrensningen avgrenser utvidelsen lengden på sertifikatkjeden, slik at den forblir håndterbar og sikker.",[153,1305,1306],{},[157,1307,1308],{},"Slik fungerer mekanismene:",[172,1310,1311,1316],{},[175,1312,1313,1315],{},[157,1314,1297],{}," Når et sertifikat utstedes, settes CA-flagget etter hva sertifikatet er ment å brukes til. Under valideringen av sertifikatet kontrollerer klientene dette flagget for å avgjøre om sertifikatet kan betros til å utstede andre sertifikater.",[175,1317,1318,1320],{},[157,1319,1261],{}," Denne verdien kontrolleres under valideringen for å sikre at sertifikatkjeden ikke overskrider den angitte lengden. Er kjeden for lang, regnes sertifikatet som ugyldig.",[153,1322,1323],{},"Disse mekanismene bidrar til å opprettholde integriteten og sikkerheten i Public Key Infrastructure (PKI) ved å sikre at bare autoriserte sertifikater kan utstede andre sertifikater, og ved å hindre unødig lange sertifikatkjeder.",{"title":435,"searchDepth":436,"depth":436,"links":1325},[1326],{"id":1116,"depth":436,"text":1117,"children":1327},[1328,1330,1331,1332,1333,1334],{"id":1120,"depth":441,"text":1329},"Hvordan viser en klient at den stoler på en bestemt rot-CA?",{"id":1163,"depth":441,"text":1164},{"id":1170,"depth":441,"text":1171},{"id":1210,"depth":441,"text":1211},{"id":1240,"depth":441,"text":1241},{"id":1284,"depth":441,"text":1285},{"lang":462,"seoTitle":1336,"titleClass":463,"socialimg":1337,"blogtitlepic":1338,"customExcerpt":1339,"keywords":1340,"maxContent":473},"Slik etableres tillit i Public Key Infrastructure: tillitsmodellen for PKI-sertifikater","/blog/heads/header-scepman-public-key-infrastructure.png","header-scepman-public-key-infrastructure.png","Etabler tillit i PKI med sertifikatkjeder, rot-CA-er og mellomliggende CA-er samt sikker validering av sertifikater.","etablere tillit PKI, tillit i public key infrastructure, sertifikatets tillitskjede, tillit til rot-CA, tillit til mellomliggende CA, tillitsmodell for PKI, validering av sertifikater, betrodde rotsertifikater, sikker verifisering av sertifikater, verifisering av tillitskjede","/glossary/public-key-infrastructure",{"title":1111,"description":435},"glossary/public-key-infrastructure","s4dwZnBqTelwMg7MrWqqcnKcxtrlmyNLoniVB59u-70",{"id":1346,"title":1347,"author":143,"body":1348,"cta":143,"description":435,"eventid":143,"extension":458,"hideInRecent":459,"layout":460,"meta":1787,"moment":143,"navigation":473,"path":1793,"seo":1794,"stem":1795,"tags":143,"webcast":459,"__hash__":1796},"content_no/glossary/use-cases-for-certificates.md","Bruksområder for sertifikater",{"type":145,"value":1349,"toc":1772},[1350,1354,1358,1372,1376,1408,1412,1443,1447,1453,1459,1463,1516,1520,1524,1538,1542,1554,1558,1561,1575,1579,1585,1596,1601,1612,1618,1629,1633,1653,1657,1660,1664,1684,1688,1705,1710,1730,1734,1737,1769],[148,1351,1353],{"id":1352},"transport-layer-security-tls","Transport Layer Security (TLS)",[165,1355,1357],{"id":1356},"hvilke-to-spørsmål-må-en-klient-stille-når-den-mottar-et-sertifikat-fra-en-server","Hvilke to spørsmål må en klient stille når den mottar et sertifikat fra en server?",[258,1359,1360,1366],{},[175,1361,1362,1365],{},[157,1363,1364],{},"Er sertifikatet gyldig og betrodd?"," Klienten må verifisere at sertifikatet er utstedt av en betrodd sertifikatmyndighet (CA), og at det verken er utløpt eller tilbakekalt. Det innebærer å kontrollere gyldighetsperioden til sertifikatet og sikre at det er signert av en CA som klienten stoler på.",[175,1367,1368,1371],{},[157,1369,1370],{},"Stemmer sertifikatet med identiteten til serveren?"," Klienten må forsikre seg om at opplysningene i sertifikatet, for eksempel Common Name (CN) eller Subject Alternative Name (SAN), stemmer med domenenavnet til serveren. Det bidrar til å bekrefte at sertifikatet virkelig er ment for serveren klienten forsøker å koble seg til.",[165,1373,1375],{"id":1374},"hvordan-validerer-klienten-at-et-sertifikat-er-til-å-stole-på","Hvordan validerer klienten at et sertifikat er til å stole på?",[258,1377,1378,1384,1390,1396,1402],{},[175,1379,1380,1383],{},[157,1381,1382],{},"Kontroller sertifikatets tillitskjede:"," Klienten verifiserer sertifikatkjeden, som består av serverens sertifikat, eventuelle mellomliggende sertifikater og rotsertifikatet. Hvert sertifikat i kjeden må være signert av myndigheten over seg, og kjeden må til slutt føre til et betrodd rotsertifikat.",[175,1385,1386,1389],{},[157,1387,1388],{},"Verifiser gyldighetsperioden til sertifikatet:"," Klienten kontrollerer gyldighetsperioden til sertifikatet for å sikre at det verken er utløpt eller ennå ikke gyldig. Det innebærer å kontrollere datoene «Not Before» og «Not After» i sertifikatet.",[175,1391,1392,1395],{},[157,1393,1394],{},"Match sertifikatet mot identiteten til serveren:"," Klienten sikrer at Common Name (CN) eller Subject Alternative Name (SAN) i sertifikatet stemmer med domenenavnet til serveren. Det bekrefter at sertifikatet er ment for serveren klienten kobler seg til.",[175,1397,1398,1401],{},[157,1399,1400],{},"Kontroller tilbakekalling:"," Klienten kontrollerer om sertifikatet er tilbakekalt, ved å slå opp i sertifikattilbakekallingslisten (CRL) eller bruke Online Certificate Status Protocol (OCSP). Et tilbakekalt sertifikat er ikke lenger betrodd.",[175,1403,1404,1407],{},[157,1405,1406],{},"Verifiser den digitale signaturen:"," Klienten verifiserer den digitale signaturen på sertifikatet for å sikre at det ikke er manipulert. Det innebærer å kontrollere den kryptografiske signaturen mot den offentlige nøkkelen til CA-en som utstedte sertifikatet.",[165,1409,1411],{"id":1410},"hvordan-validerer-klienten-at-serveren-virkelig-eier-sertifikatet","Hvordan validerer klienten at serveren virkelig eier sertifikatet?",[258,1413,1414,1420,1426,1432,1438],{},[175,1415,1416,1419],{},[157,1417,1418],{},"Verifisering av sertifikatkjeden:"," Klienten verifiserer sertifikatkjeden og sikrer at hvert sertifikat i kjeden er signert av en betrodd sertifikatmyndighet (CA). Kjeden starter ved serverens sertifikat og ender ved et betrodd rotsertifikat.",[175,1421,1422,1425],{},[157,1423,1424],{},"Match av domenenavn:"," Klienten kontrollerer at Common Name (CN) eller Subject Alternative Name (SAN) i sertifikatet stemmer med domenenavnet til serveren. Det sikrer at sertifikatet er ment for serveren klienten kobler seg til.",[175,1427,1428,1431],{},[157,1429,1430],{},"Verifisering av den digitale signaturen:"," Klienten verifiserer den digitale signaturen på sertifikatet med den offentlige nøkkelen til CA-en som utstedte det. Det sikrer at sertifikatet ikke er manipulert, og at det virkelig er utstedt av en betrodd CA.",[175,1433,1434,1437],{},[157,1435,1436],{},"Gyldighetsperioden til sertifikatet:"," Klienten kontrollerer gyldighetsperioden til sertifikatet for å sikre at det er gyldig nå og ikke er utløpt.",[175,1439,1440,1401],{},[157,1441,1442],{},"Kontroll av tilbakekallingsstatus:",[165,1444,1446],{"id":1445},"hvorfor-er-eierskapet-viktig-når-du-allerede-har-kontrollert-at-sertifikatet-er-betrodd","Hvorfor er eierskapet viktig når du allerede har kontrollert at sertifikatet er betrodd?",[153,1448,1449,1452],{},[157,1450,1451],{},"Sertifikatets gyldighet og tillit:"," Dette trinnet sikrer at sertifikatet er utstedt av en betrodd sertifikatmyndighet (CA), er innenfor gyldighetsperioden sin og ikke er tilbakekalt. Det bekrefter at sertifikatet er legitimt og ikke manipulert.",[153,1454,1455,1458],{},[157,1456,1457],{},"Verifisering av serveridentiteten:"," Selv om et sertifikat er gyldig og betrodd, må det også bekreftes at det hører til serveren du kobler deg til. Det innebærer å kontrollere at Common Name (CN) eller Subject Alternative Name (SAN) i sertifikatet stemmer med domenenavnet til serveren. Dette trinnet sikrer at sertifikatet er ment for nettopp den serveren, og hindrer mellommannsangrep der en angriper kan legge fram et gyldig sertifikat for et annet domene.",[165,1460,1462],{"id":1461},"hvilke-to-metoder-bruker-klienten-til-å-svare-på-dette-spørsmålet-og-hvilke-to-utfall-gir-hver-av-metodene","Hvilke to metoder bruker klienten til å svare på dette spørsmålet, og hvilke to utfall gir hver av metodene?",[258,1464,1465,1492],{},[175,1466,1467,1470,1471,1474,1477,1478],{},[157,1468,1469],{},"Verifisering via Domain Name System (DNS):"," Klienten kontrollerer at Common Name (CN) eller Subject Alternative Name (SAN) i sertifikatet stemmer med domenenavnet til serveren. ",[1472,1473],"br",{},[157,1475,1476],{},"Utfall",":",[172,1479,1480,1486],{},[175,1481,1482,1485],{},[157,1483,1484],{},"Treff",": Stemmer navnene, kan klienten fortsette med forbindelsen, trygg på at sertifikatet er ment for serveren. ",[175,1487,1488,1491],{},[157,1489,1490],{},"Avvik",": Stemmer navnene ikke, avslutter klienten sannsynligvis forbindelsen eller viser en advarsel om en mulig sikkerhetsrisiko.",[175,1493,1494,1497,1498,1500,1477,1502],{},[157,1495,1496],{},"Verifisering via Public Key Infrastructure (PKI):"," Klienten verifiserer den digitale signaturen på sertifikatet med den offentlige nøkkelen til sertifikatmyndigheten (CA) som utstedte det. ",[1472,1499],{},[157,1501,1476],{},[172,1503,1504,1510],{},[175,1505,1506,1509],{},[157,1507,1508],{},"Gyldig signatur",": Er signaturen gyldig, bekrefter det at sertifikatet ikke er manipulert, og at det er utstedt av en betrodd CA.",[175,1511,1512,1515],{},[157,1513,1514],{},"Ugyldig signatur:"," Er signaturen ugyldig, avslutter klienten forbindelsen eller viser en advarsel om at sertifikatet kan være kompromittert eller forfalsket.",[165,1517,1519],{"id":1518},"hva-avgjør-hvilken-metode-som-brukes","Hva avgjør hvilken metode som brukes?",[153,1521,1522],{},[157,1523,1469],{},[172,1525,1526,1532],{},[175,1527,1528,1531],{},[157,1529,1530],{},"Bruk",": Denne metoden brukes alltid som en del av TLS-håndtrykket. Klienten kontrollerer Common Name (CN) eller Subject Alternative Name (SAN) i sertifikatet mot domenenavnet til serveren for å se at de stemmer.",[175,1533,1534,1537],{},[157,1535,1536],{},"Avgjørende faktorer:"," Dette er en standard del av TLS-protokollen og utføres automatisk av klienten når en sikker forbindelse opprettes.",[153,1539,1540],{},[157,1541,1496],{},[172,1543,1544,1549],{},[175,1545,1546,1548],{},[157,1547,1530],{},": Denne metoden brukes også alltid under TLS-håndtrykket. Klienten verifiserer den digitale signaturen på sertifikatet med den offentlige nøkkelen til sertifikatmyndigheten (CA) som utstedte det.",[175,1550,1551,1553],{},[157,1552,1536],{}," Dette er nok en standard del av TLS-protokollen. Klienten utfører denne kontrollen automatisk for å sikre at sertifikatet er gyldig og ikke manipulert.",[148,1555,1557],{"id":1556},"hvilke-sertifikater-bør-serveren-sende-til-klienten","Hvilke sertifikater bør serveren sende til klienten?",[153,1559,1560],{},"Under TLS-håndtrykket bør serveren sende følgende sertifikater til klienten:",[172,1562,1563,1569],{},[175,1564,1565,1568],{},[157,1566,1567],{},"Sluttsertifikat:"," Dette er serverens eget sertifikat, som beviser identiteten dens overfor klienten.",[175,1570,1571,1574],{},[157,1572,1573],{},"Mellomliggende sertifikater:"," Disse sertifikatene knytter sluttsertifikatet til det betrodde rotsertifikatet. De bidrar til å etablere en tillitskjede fra serverens sertifikat tilbake til et betrodd rotsertifikat.",[148,1576,1578],{"id":1577},"hva-er-domain-validation-og-extended-validation-sertifikater","Hva er Domain Validation- og Extended Validation-sertifikater?",[153,1580,1581,1584],{},[157,1582,1583],{},"Domain Validation-sertifikater (DV)"," er en type TLS-sertifikat der sertifikatmyndigheten (CA) verifiserer at søkeren har kontroll over domenet. Det gjøres vanligvis slik:",[172,1586,1587,1590,1593],{},[175,1588,1589],{},"Ved å svare på en e-post sendt til den administrative kontakten for domenet.",[175,1591,1592],{},"Ved å legge til en DNS TXT-oppføring.",[175,1594,1595],{},"Ved å laste opp en fil til webserveren.",[153,1597,1598],{},[157,1599,1600],{},"Viktige kjennetegn:",[172,1602,1603,1606,1609],{},[175,1604,1605],{},"Rask utstedelse: De kan utstedes raskt, ofte i løpet av minutter, fordi de krever minimal validering.",[175,1607,1608],{},"Grunnleggende sikkerhet: De gir kryptering og en grunnleggende forsikring om at domenet kontrolleres av den som ber om sertifikatet.",[175,1610,1611],{},"Kostnadseffektive: Ofte billigere eller til og med gratis, noe som gjør dem tilgjengelige for små nettsteder og private prosjekter.",[153,1613,1614,1617],{},[157,1615,1616],{},"Extended Validation-sertifikater (EV)"," er TLS-sertifikater på et høyere nivå som krever en grundigere valideringsprosess. CA-en verifiserer at virksomheten som ber om sertifikatet, finnes juridisk, fysisk og operasjonelt. Det omfatter:",[172,1619,1620,1623,1626],{},[175,1621,1622],{},"Å bekrefte den juridiske identiteten og statusen til virksomheten.",[175,1624,1625],{},"Å verifisere den fysiske og operasjonelle tilstedeværelsen til virksomheten.",[175,1627,1628],{},"Å sikre at virksomheten har enerett til å bruke domenet.",[153,1630,1631],{},[157,1632,1600],{},[172,1634,1635,1641,1647],{},[175,1636,1637,1640],{},[157,1638,1639],{},"Høy grad av sikkerhet:"," Gir brukerne det høyeste nivået av tillit og trygghet, fordi kontrollen er grundig.",[175,1642,1643,1646],{},[157,1644,1645],{},"Synlige indikatorer:"," I enkelte nettlesere pleide EV-sertifikater å vise navnet på virksomheten i adressefeltet, men det er mindre vanlig i dag.",[175,1648,1649,1652],{},[157,1650,1651],{},"Styrket tillit:"," Ideelt for nettsteder som håndterer sensitiv informasjon, for eksempel finansinstitusjoner og netthandelssteder.",[165,1654,1656],{"id":1655},"hvilke-er-sikrest"," Hvilke er sikrest?",[153,1658,1659],{},"Extended Validation-sertifikater (EV) regnes stort sett som sikrere enn Domain Validation-sertifikater (DV) på grunn av den grundige valideringsprosessen de går gjennom. Her er en sammenligning:",[153,1661,1662],{},[157,1663,1583],{},[172,1665,1666,1672,1678],{},[175,1667,1668,1671],{},[157,1669,1670],{},"Valideringsnivå:"," Verifiserer bare kontroll over domenet.",[175,1673,1674,1677],{},[157,1675,1676],{},"Sikkerhet:"," Gir grunnleggende kryptering og trygghet.",[175,1679,1680,1683],{},[157,1681,1682],{},"Bruksområde:"," Egnet for private nettsteder, blogger og små virksomheter.",[153,1685,1686],{},[157,1687,1616],{},[172,1689,1690,1695,1700],{},[175,1691,1692,1694],{},[157,1693,1670],{}," Verifiserer at virksomheten finnes juridisk, fysisk og operasjonelt.",[175,1696,1697,1699],{},[157,1698,1676],{}," Gir et høyere nivå av tillit og trygghet takket være den grundige kontrollen.",[175,1701,1702,1704],{},[157,1703,1682],{}," Ideelt for finansinstitusjoner, netthandelssteder og alle nettsteder som håndterer sensitiv informasjon.",[153,1706,1707],{},[157,1708,1709],{},"Derfor er EV-sertifikater sikrere:",[172,1711,1712,1718,1724],{},[175,1713,1714,1717],{},[157,1715,1716],{},"Grundig kontroll:"," EV-sertifikater krever omfattende validering, noe som gjør det vanskeligere for ondsinnede aktører å skaffe seg dem.",[175,1719,1720,1723],{},[157,1721,1722],{},"Tillitsindikatorer:"," Selv om det er mindre vanlig i dag, pleide EV-sertifikater å vise navnet på virksomheten i adressefeltet i nettleseren, og ga brukerne en synlig bekreftelse.",[175,1725,1726,1729],{},[157,1727,1728],{},"Høyere grad av sikkerhet:"," Den detaljerte verifiseringsprosessen sikrer at virksomheten bak sertifikatet er legitim, og reduserer risikoen for phishing og andre angrep.",[148,1731,1733],{"id":1732},"hvordan-foregår-tilbakekalling-med-ocsp-stapling","Hvordan foregår tilbakekalling med OCSP-stapling",[153,1735,1736],{},"OCSP-stapling forbedrer den vanlige OCSP-prosessen ved å redusere forsinkelsen og styrke personvernet. Slik fungerer det:",[258,1738,1739,1745,1751,1757,1763],{},[175,1740,1741,1744],{},[157,1742,1743],{},"Serveren ber om et OCSP-svar:"," Webserveren ber med jevne mellomrom OCSP-responderen, en server som driftes av sertifikatmyndigheten (CA), om tilbakekallingsstatusen til sertifikatet sitt. Denne forespørselen skjer i bakgrunnen og ikke ved hver klientforbindelse.",[175,1746,1747,1750],{},[157,1748,1749],{},"OCSP-responderen gir et svar:"," OCSP-responderen sender tilbake et signert OCSP-svar med tidsstempel som angir statusen til sertifikatet, for eksempel «good», «revoked» eller «unknown». Serveren mellomlagrer dette svaret.",[175,1752,1753,1756],{},[157,1754,1755],{},"TLS-håndtrykk med vedlagt svar:"," Når en klient, for eksempel en nettleser, oppretter en forbindelse til serveren, legger serveren det mellomlagrede OCSP-svaret ved TLS-håndtrykket. Dette kalles å «stifte» svaret til håndtrykket.",[175,1758,1759,1762],{},[157,1760,1761],{},"Klienten verifiserer OCSP-svaret:"," Klienten verifiserer det vedlagte OCSP-svaret. Siden svaret er signert av CA-en, kan klienten stole på at det er gyldig. Sier svaret at sertifikatet er tilbakekalt, oppretter ikke klienten noen sikker forbindelse.",[175,1764,1765,1768],{},[157,1766,1767],{},"Jevnlige oppdateringer:"," Serveren fortsetter å oppdatere det mellomlagrede OCSP-svaret med jevne mellomrom, slik at den alltid har en gjeldende status å gi under TLS-håndtrykket.",[153,1770,1771],{},"Denne prosessen reduserer behovet for at klienter må sende egne OCSP-forespørsler, og forbedrer dermed ytelsen og personvernet.",{"title":435,"searchDepth":436,"depth":436,"links":1773},[1774,1782,1783,1786],{"id":1352,"depth":436,"text":1353,"children":1775},[1776,1777,1778,1779,1780,1781],{"id":1356,"depth":441,"text":1357},{"id":1374,"depth":441,"text":1375},{"id":1410,"depth":441,"text":1411},{"id":1445,"depth":441,"text":1446},{"id":1461,"depth":441,"text":1462},{"id":1518,"depth":441,"text":1519},{"id":1556,"depth":436,"text":1557},{"id":1577,"depth":436,"text":1578,"children":1784},[1785],{"id":1655,"depth":441,"text":1656},{"id":1732,"depth":436,"text":1733},{"lang":462,"seoTitle":1788,"titleClass":463,"socialimg":1789,"blogtitlepic":1790,"customExcerpt":1791,"keywords":1792,"maxContent":473},"Transport Layer Security (TLS): bruksområder og validering av sertifikater","/blog/heads/header-scepman-use-cases-certificates.png","header-scepman-use-cases-certificates.png","Beskytt nettstedet og brukerne dine med TLS-sertifikater som verifiserer servere, bygger tillit gjennom sertifikatkjeder og sikrer trygge, krypterte forbindelser.","TLS-sertifikater, Transport Layer Security, bruksområder for sertifikater, validering av TLS-sertifikater, sertifikatets tillitskjede, DV-sertifikater, EV-sertifikater, serverautentisering, sikre forbindelser, OCSP-stapling","/glossary/use-cases-for-certificates",{"title":1347,"description":435},"glossary/use-cases-for-certificates","KVJY-mRRhGUwc70_JCyjBijCfD3GrXpr2w44LfVMI_U",{"list":139,"authors":143},1790098990218]