[{"data":1,"prerenderedAt":1799},["ShallowReactive",2],{"sc:header-data-da":3,"sc:footer-data-da":101,"glossary-posts-da":139,"content-da-list-c077398beed29":1798},{"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",{"da":10},{"title":11,"url":12,"alt":13},"Forside","/da","SCEPman",[15,19,25,31,83,89],{"name":16,"languages":17},"nav-home",{"da":18},{"title":11,"url":12},{"name":20,"languages":21},"pricing",{"da":22},{"title":23,"url":24},"Priser","/da/pricing",{"name":26,"languages":27},"partner",{"da":28},{"title":29,"url":30},"Partnere","/da/partner",{"name":32,"languages":33,"children":36},"support-hub",{"da":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",{"da":44},{"title":45,"url":46},"Docs","https://docs.scepman.com/",{"name":48,"languages":49},"faq",{"da":50},{"title":51,"url":52},"FAQ","/da/faq",{"name":54,"children":55},"support-hub-group-2",[56,62],{"name":57,"target":42,"languages":58},"support-ticket",{"da":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",{"da":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",{"da":74},{"title":75,"url":76},"Ordliste","/da/glossary",{"name":78,"languages":79},"blog",{"da":80},{"title":81,"url":82},"Blog","/da/blog",{"name":84,"languages":85},"events",{"da":86},{"title":87,"url":88},"Arrangementer","/da/events",{"name":90,"languages":91},"about",{"da":92},{"title":93,"url":94},"Om os","/da/about-us",{"name":96,"languages":97},"contact",{"da":98},{"title":99,"url":100},"support@scepman.com","mailto:support@scepman.com",{"data":102},{"mail":103,"logos":104,"socials":109,"links":122,"linksDa":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},"Privatlivspolitik",{"title":136,"url":128,"target":42},"Juridisk information",{"title":138,"url":131,"target":42},"Kontakt og adresser",[140,478,851,1110,1346],{"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_da/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øglebaseret-kryptering-findes-der","Hvilke to typer nøglebaseret kryptering findes der?",[153,154,155,156,160,161],"p",{},"De to hovedtyper af nøglebaseret 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],{},"Brug af nøgler",": Bruger en enkelt nøgle til både kryptering og dekryptering.",[175,182,183,186],{},[157,184,185],{},"Hastighed",": Generelt hurtigere og mere effektiv.",[175,188,189,192],{},[157,190,191],{},"Sikkerhed",": Den største udfordring er at dele nøglen sikkert mellem parterne.",[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],{},": Bruger et nøglepar, nemlig en offentlig nøgle til kryptering og en privat nøgle til dekryptering.",[175,213,214,216],{},[157,215,185],{},": Langsommere end symmetrisk kryptering, fordi beregningerne er mere komplekse.",[175,218,219,221],{},[157,220,191],{},": Mere sikker ved distribution af nøgler, fordi den private nøgle aldrig deles.",[175,223,224,226],{},[157,225,197],{},": RSA (Rivest-Shamir-Adleman), ECC (Elliptic Curve Cryptography).",[165,228,230],{"id":229},"hvilken-type-kryptering-anses-for-mest-sikker","Hvilken type kryptering anses for mest sikker?",[153,232,233],{},"Begge metoder betragtes som sikre i den forstand, at ingen nuværende computer kan bryde krypteringen, hvis du bruger en moderne algoritme med tilstrækkelig nøglelængde.",[153,235,236],{},"Hvilken type kryptering der er bedst, afhænger af anvendelsen, men mange anvendelser kræver asymmetrisk kryptering, fordi den bruger et nøglepar: en offentlig nøgle til kryptering og en privat nøgle til dekryptering. Den private nøgle holdes hemmelig, og det styrker sikkerheden, fordi den aldrig skal deles.",[165,238,240,241],{"id":239},"hvilken-type-kryptering-er-bedst-til-store-datamængder","Hvilken type kryptering er bedst til store datamængder? ",[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 hurtigere.",[165,250,252,253],{"id":251},"hvordan-foregår-hybrid-kryptering-overordnet","Hvordan foregår hybrid kryptering overordnet? ",[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øglegenerering",": Afsenderen genererer en ny symmetrisk nøgle (også kaldet en sessionsnøgle) til at kryptere selve beskeden.",[175,267,268,271],{},[157,269,270],{},"Kryptering af beskeden",": Afsenderen bruger den symmetriske nøgle til at kryptere klartekstbeskeden, hvilket giver en chiffertekst.",[175,273,274,277],{},[157,275,276],{},"Kryptering af nøglen",": Derefter krypterer afsenderen den symmetriske nøgle med modtagerens offentlige nøgle (asymmetrisk kryptering).",[175,279,280,283],{},[157,281,282],{},"Overførsel",": Afsenderen sender både den krypterede besked (chifferteksten) og den krypterede symmetriske nøgle til modtageren.",[175,285,286,289],{},[157,287,288],{},"Dekryptering af nøglen",": Modtageren bruger sin private nøgle til at dekryptere den symmetriske nøgle.",[175,291,292,295],{},[157,293,294],{},"Dekryptering af beskeden",": Til sidst bruger modtageren den dekrypterede symmetriske nøgle til at dekryptere chifferteksten og få den oprindelige klartekst frem.",[148,297,299],{"id":298},"hashalgoritmer","Hashalgoritmer",[153,301,302],{},"En hashalgoritme er en matematisk funktion, der omdanner inputdata af vilkårlig størrelse til en tegnstreng med fast længde, typisk en sekvens af bogstaver og tal. Outputtet kaldes en hashværdi eller et digest.",[165,304,306],{"id":305},"hvad-er-en-kollision","Hvad er en kollision?",[153,308,309],{},"En kollision i hashing opstår, når to forskellige datastykker giver den samme hashværdi med en hashalgoritme. Det kan være et problem, fordi hovedformålet med en hashalgoritme er at repræsentere forskellige datainput entydigt.",[165,311,313],{"id":312},"hvad-er-en-mac","Hvad er en MAC?",[153,315,316],{},"Message Authentication Code (MAC): I kryptografi er en MAC et kort stykke information, der bruges til at autentificere en besked og sikre dens integritet. Den bekræfter, at beskeden ikke er ændret, og fastslår afsenderens identitet.",[165,318,320],{"id":319},"hvad-er-forskellen-på-en-mac-og-en-hmac","Hvad er forskellen på en MAC og en HMAC?",[153,322,323],{},"MAC: En generel betegnelse for en kode, der verificerer en beskeds integritet og ægthed ved hjælp af enten blokchifre eller hashfunktioner.",[153,325,326],{},"HMAC: En bestemt type MAC, der bruger en kryptografisk hashfunktion og en hemmelig nøgle og dermed giver stærkere sikkerhedsegenskaber.",[148,328,330],{"id":329},"asymmetrisk-kryptografi","Asymmetrisk kryptografi",[165,332,334],{"id":333},"hvordan-foregår-signering-af-beskeder-overordnet","Hvordan foregår signering af beskeder overordnet?",[153,336,337],{},"Signering af beskeder er en kryptografisk proces, der bruges til at verificere en beskeds ægthed og integritet.",[258,339,340,346,352,358],{},[175,341,342,345],{},[157,343,344],{},"Dannelse af hashværdien:"," Afsenderen genererer et unikt digitalt fingeraftryk (en hashværdi) af beskeden med en kryptografisk hashfunktion (for eksempel SHA-256). Hashværdien repræsenterer beskedens indhold entydigt.",[175,347,348,351],{},[157,349,350],{},"Signering:"," Afsenderen krypterer hashværdien med sin private nøgle og danner dermed den digitale signatur. Det sikrer, at signaturen kun kan dannes af nogen med adgang til afsenderens private nøgle.",[175,353,354,357],{},[157,355,356],{},"Afsendelse:"," Den digitale signatur vedhæftes beskeden, og begge dele sendes til modtageren. Afsenderens offentlige nøgle stilles også til rådighed, så signaturen kan verificeres.",[175,359,360,363],{},[157,361,362],{},"Verifikation:"," Modtageren bruger afsenderens offentlige nøgle til at dekryptere den digitale signatur og få den oprindelige hashværdi frem. Derefter danner modtageren en ny hashværdi ud fra den modtagne besked og sammenligner den med den dekrypterede hashværdi. Hvis de stemmer overens, bekræfter det, at beskeden ikke er ændret, og det verificerer afsenderens identitet.",[165,365,367],{"id":366},"hvilke-tre-funktioner-har-asymmetrisk-kryptering","Hvilke tre funktioner har asymmetrisk kryptering?",[153,369,370],{},"Asymmetrisk kryptering, også kaldet offentlig nøgle-kryptografi, har flere vigtige funktioner, når kommunikation 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øgleudveksling",[165,389,391],{"id":390},"rsa","RSA",[153,393,394],{},"RSA, en forkortelse for Rivest-Shamir-Adleman, er et udbredt kryptosystem med offentlig nøgle til sikker dataoverførsel. Det er opkaldt efter opfinderne Ronald Rivest, Adi Shamir og Leonard Adleman, som præsenterede det i 1977.",[165,396,398],{"id":397},"diffie-hellman","Diffie-Hellman",[153,400,401],{},"Diffie-Hellman-nøgleudveksling er en metode i kryptografi til sikkert at udveksle kryptografiske nøgler over en offentlig kanal. Den blev udviklet af Whitfield Diffie og Martin Hellman i 1976. Formålet med Diffie-Hellman-nøgleudveksling er at gøre det muligt for to parter sikkert at danne en fælles hemmelig nøgle, som kan bruges til at kryptere den efterfølgende kommunikation.",[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øgle, der bruges til at danne og verificere digitale signaturer. Den blev foreslået af National Institute of Standards and Technology (NIST) i 1991 som en del af Digital Signature Standard (DSS).",[410,411,413],"h4",{"id":412},"sådan-fungerer-det","Sådan fungerer det",[258,415,416,422,428],{},[175,417,418,421],{},[157,419,420],{},"Nøglegenerering:"," DSA genererer et nøglepar: en privat nøgle til signering og en offentlig nøgle til verifikation.",[175,423,424,427],{},[157,425,426],{},"Signering",": Afsenderen bruger sin private nøgle til at danne en digital signatur på en besked. Signaturen er unik for både beskeden og den private nøgle.",[175,429,430,433],{},[157,431,432],{},"Verifikation",": Modtageren bruger afsenderens offentlige nøgle til at verificere signaturens ægthed og dermed beskedens integritet og oprindelse.",{"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},"da","h1-font-size","header-scepman-cryptography.png","/blog/heads/header-scepman-cryptography.png","Den centrale udfordring ved registrering af certifikater er, hvordan den enhed eller bruger, der anmoder om certifikatet, autentificeres. Med certifikatet bekræfter CA'en, at certifikatindehaveren har bestemte egenskaber, og at den har kontrolleret, om de er ægte",{"menuItems":468},[469,471],{"href":470,"text":299},"#hashalgoritmer",{"href":472,"text":330},"#asymmetrisk-kryptografi",true,"/glossary/cryptography",{"title":142,"description":435},"glossary/cryptography","K1YLw0MgUF1foTg0ISTKW0LDNUlDGuEy47WaGoz8s9c",{"id":479,"title":480,"author":143,"body":481,"cta":143,"description":485,"eventid":143,"extension":458,"hideInRecent":459,"layout":460,"meta":835,"moment":143,"navigation":473,"path":847,"seo":848,"stem":849,"tags":143,"webcast":459,"__hash__":850},"content_da/glossary/enrollment-methods.md","Registreringsmetoder",{"type":145,"value":482,"toc":822},[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,749,753,756,762,766,775,778,781,784,801,812,815,818],[153,484,485],{},"En central egenskab ved protokoller til certifikatregistrering er derfor, hvordan de autentificerer den, der anmoder om certifikatet. Afhængigt af hvad certifikatet skal bruges til, er den ene eller den anden protokol mest fordelagtig.",[153,487,488],{},"En anden vigtig egenskab er den praktiske udbredelse. Registreringsmetoden eller protokollen skal understøttes både af CA'en og på klientsiden til det tiltænkte formål.",[153,490,491],{},"De mest udbredte registreringsprotokoller 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","Microsofts RPC/DCOM",[175,513,514],{},"Microsofts SOAP",[175,516,517],{},"Manuel registrering på CA'ens webside",[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],{},"Microsofts proprietære DCOM og 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",{},"Specifikationer",[553,557,558],{},"Microsoft OpenSpec1",[553,560,561],{},"Microsoft OpenSpec2",[553,563,564],{},"RFC 8555",[553,566,567],{},"Uformel, nu 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],{},"Ringe udbredelse",[529,592,531,593,531,596,531,599,531,602,531,605,531,608,524],{},[553,594,595],{},"Autentificering",[553,597,598],{},"AD-autentificering",[553,600,601],{},"AD-autentificering\\* (formelt behøver brugernavn og adgangskode ikke at ligge i AD)",[553,603,604],{},"DNS-autentificering",[553,606,607],{},"“SCEP Challenge”",[553,609,610],{},"CBA eller HTTP Basic- eller Digest-autentificering",[148,612,499],{"id":498},[165,614,616],{"id":615},"historie-og-specifikation","Historie og specifikation",[153,618,619,620,626],{},"Cisco opfandt oprindeligt Simple Certificate Enrollment Protocol (SCEP). Selvom der dengang ikke fandtes nogen standard, blev protokollen udbredt i MDM-systemer. Cisco gik endda videre og udviklede en efterfølger, Enrollment over Secure Transport (EST), som skulle afløse SCEP. Derfor blev EST gjort til en offentlig standard i RFC 7030 langt tidligere end SCEP, der først blev standardiseret i ",[242,621,625],{"href":622,"rel":623},"https://www.rfc-editor.org/rfc/rfc8894.html",[624],"nofollow","RFC 8894"," meget senere, da den allerede var de facto-standarden for certifikatregistrering i MDM-systemer.",[165,628,630],{"id":629},"teknologi","Teknologi",[153,632,633,634,638,639,643,644,648],{},"SCEP er HTTP-baseret. En SCEP-anmodning er en krypteret og signeret ",[242,635,637],{"href":636},"important-data-formats#pkcs7","PKCS#7",", der sendes via en GET- eller POST-anmodning til SCEP-tjenesten. Tjenesten svarer med et SCEP-svar, igen en krypteret og signeret PKCS#7. Anmodningen indeholder en ",[242,640,642],{"href":641},"important-data-formats#pkcs10","PKCS#10","-certifikatanmodning, og svaret indeholder det udstedte ",[242,645,647],{"href":646},"important-data-formats#x509","X.509-certifikat",".",[165,650,595],{"id":651},"autentificering",[153,653,654],{},"PKCS#10-anmodningen indeholder en \"SCEP Challenge\", der autentificerer og autoriserer signeringsanmodningen via en metode uden for båndet, afhængigt af den konkrete SCEP-tjeneste. Der bruges tre slags SCEP Challenges i praksis i dag:",[410,656,658],{"id":657},"statisk-scep-challenge","Statisk SCEP Challenge",[153,660,661],{},"Den enkleste mulighed er en statisk adgangssætning. Hvis SCEP Challenge i PKCS#10 svarer til en foruddefineret værdi, der er gemt på SCEP-tjenesten, bliver certifikatet udstedt, ellers bliver anmodningen afvist. Problemet med denne metode er, at det stort set ikke er muligt at kontrollere, om de ønskede egenskaber ved certifikatet passer til den, der anmoder. Der findes endda en CVE for det problem.",[153,663,664],{},"Metoderne kan inddeles yderligere:",[258,666,667,675,682],{},[175,668,669,670,674],{},"Ved en ",[671,672,673],"em",{},"direkte"," SCEP-registrering kommunikerer den enhed, certifikatet skal udstedes til, direkte med SCEP-tjenesten. For eksempel beder et MDM-system en Android-telefon om at foretage en SCEP-registrering med SCEP Challenge \"SecurePassword\". Android-telefonen genererer en CSR, forhåbentlig med de rigtige værdier, og tilføjer \"SecurePassword\" som SCEP Challenge. Derefter sender den CSR'en til SCEP-tjenesten og får det udstedte certifikat retur.",[175,676,677,678,681],{},"En ",[671,679,680],{},"transparent SCEP-proxy"," fungerer ligesom en HTTP-reverse proxy. Fordi SCEP er krypteret og signeret, kan den ikke se ind i SCEP-anmodninger eller -svar og heller ikke ændre dem, men den kan styre, hvem der kan registrere certifikater, og hvornår, ud fra netværkets perimeter.",[175,683,677,684,687],{},[671,685,686],{},"protokoladapter-SCEP-proxy"," er et system, der anmoder om certifikater via SCEP på vegne af et andet system. For eksempel kan et MDM-system som JAMF anmode en SCEP-tjeneste om et certifikat på vegne af en iPhone. Når systemet har certifikatet og den private nøgle, kan det udrulle certifikatet via en anden protokol. På den måde er det kun MDM-systemet, der har adgang til SCEP Challenge, og det kan også styre indholdet i certifikatet.",[410,689,691],{"id":690},"dynamisk-scep-challenge","Dynamisk SCEP Challenge",[153,693,694],{},"Her er hver SCEP Challenge kun gyldig til én enkelt certifikatanmodning. Det gør det muligt for SCEP-tjenesten at identificere SCEP-anmodningen og kontrollere, at de ønskede certifikategenskaber svarer til dem, der er tilladt for den konkrete anmodning.",[153,696,697],{},"Der bruges typisk to fremgangsmåder i praksis, når et MDM-system og en SCEP-CA skal blive enige om en SCEP Challenge til en anmodning:",[258,699,700,708],{},[175,701,702,703],{},"MDM-systemet beder SCEP-tjenesten om en engangskode til en SCEP-anmodning, når det har brug for en.\n",[258,704,705],{},[175,706,707],{},"Et eksempel er Microsoft NDES. NDES har en separat administrationsside, der autentificeres med AD-legitimationsoplysninger. Hver gang siden åbnes, danner og viser den en ny engangskode, som kan bruges til én enkelt SCEP-anmodning. I den konfiguration kontrollerer NDES dog ingen egenskaber ved certifikatet, fordi engangskoden er generisk.",[175,709,710],{},"MDM-systemet danner en engangskode, når det beder et administreret system om at anmode om et certifikat via SCEP. Når SCEP-anmodningen når frem til SCEP-tjenesten, skal tjenesten hente engangskoden fra MDM-systemet, som regel med en webhook, og kontrollere, om den svarer til SCEP Challenge i anmodningen. Der findes ingen standard for den protokol, så MDM-systemet og SCEP-tjenesten må blive enige om et format, og det afhænger af implementeringen, om nogen egenskaber ved anmodningen bliver kontrolleret.",[410,712,714],{"id":713},"signerede-metadata","Signerede metadata",[153,716,717],{},"Der er praktisk talt ingen længdebegrænsning på SCEP Challenge. Den behøver derfor ikke at være en adgangssætning, som mennesker kan læse, men kan også være en BLOB.",[153,719,720],{},"Intune bruger en signeret og krypteret XML som SCEP Challenge. Intune danner denne XML på serversiden og sender den til en klientenhed, når enheden skal registrere et certifikat og danne SCEP-anmodningen.",[153,722,723],{},"SCEP-tjenesten skal sende hele PKCS#10-anmodningen til en SCEP Challenge-tjeneste i Intune. SCEP Challenge-tjenesten har den private nøgle til at dekryptere XML'en og den offentlige nøgle til at kontrollere, at den er dannet af en ægte Intune-tjeneste.",[153,725,726],{},"XML'en indeholder metadata om anmodningen, for eksempel hvordan subject skal se ud. Det udledes dels af SCEP-konfigurationsprofilen, dels af de konkrete objektdata for den bruger eller enhed, certifikatet skal udstedes til.",[153,728,729],{},"SCEP-konfigurationsprofilen kan for eksempel angive CN={{DeviceId}} som subject. Når enheden med id xyz anmoder om et certifikat, står der i XML'en, at subject skal være CN=xyz. SCEP Challenge-tjenesten sammenligner derefter oplysningerne fra XML'en med subject i PKCS#10-anmodningen. Valideringen mislykkes, hvis de to subjects er forskellige, og den lykkes, hvis denne og de øvrige egenskaber stemmer overens.",[153,731,732],{},"SCEP-tjenesten udsteder kun certifikatet, 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 artikel"," der forklarer denne verifikation.",[153,743,744],{},"Microsoft NDES understøtter det med et ekstra NDES Policy Module, mens andre SCEP-CA'er kan understøtte det indbygget eller lade være.",[148,746,748],{"id":747},"microsoft-rpcdcom","Microsoft RPC/DCOM",[165,750,752],{"id":751},"historie","Historie",[153,754,755],{},"Microsoft Active Directory Certificate Services (ADCS), som nogle gange bare kaldes \"Microsoft CA\", er den software til certifikatmyndigheder, der er indbygget i Windows Server. Softwaren blev oprindeligt udviklet i slutningen af det forrige årtusinde og fik løbende tilføjelser de følgende ti til femten år.",[153,757,758,759,761],{},"Et alternativ er Microsofts SOAP eller ",[242,760,499],{"href":498},", som Microsoft kalder henholdsvis Web Enrollment og NDES.",[165,763,765],{"id":764},"specifikation-og-udbredelse","Specifikation og udbredelse",[153,767,768,769,774],{},"Vi kender ikke til andre CA-systemer, der implementerer denne protokol, selvom Microsoft i mellemtiden har offentliggjort ",[242,770,773],{"href":771,"rel":772},"https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cersod/dd034cb3-99fc-4c10-92c8-1fbeb4788183",[624],"specifikationen i Microsoft OpenSpec",". På klientsiden understøtter Windows protokollen indbygget, mens andre platforme ikke understøttes.",[165,776,630],{"id":777},"teknologi-1",[153,779,780],{},"Den primære registreringsmetode er en proprietær protokol baseret på RPC eller DCOM.",[153,782,783],{},"Automatisk registrering bruger også denne protokol. For at automatisk registrering kan fungere, skal du have",[172,785,786,789,792,795,798],{},[175,787,788],{},"en enhed, der er tilmeldt domænet.",[175,790,791],{},"en gruppepolitik, der aktiverer automatisk registrering,",[175,793,794],{},"en Enterprise CA (i modsætning til en stand-alone CA)",[175,796,797],{},"som udsteder efter en certifikatskabelon, hvor",[175,799,800],{},"brugeren eller enheden har tilladelser til registrering og automatisk registrering.",[153,802,803,804,808,809,648],{},"Standardintervallet for kontrol af automatiske registreringer er 8 timer, men det kan fremtvinges med ",[805,806,807],"code",{},"certutil -pulse"," eller ofte bedre med ",[805,810,811],{},"gpupdate -force",[165,813,595],{"id":814},"autentificering-1",[153,816,817],{},"Protokollen bruger de autentificeringsprotokoller, der er indbygget i Active Directory, altså autentificerer brugere og computere sig med deres AD-legitimationsoplysninger.",[819,820,821],"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":823},[824,829],{"id":498,"depth":436,"text":499,"children":825},[826,827,828],{"id":615,"depth":441,"text":616},{"id":629,"depth":441,"text":630},{"id":651,"depth":441,"text":595},{"id":747,"depth":436,"text":748,"children":830},[831,832,833,834],{"id":751,"depth":441,"text":752},{"id":764,"depth":441,"text":765},{"id":777,"depth":441,"text":630},{"id":814,"depth":441,"text":595},{"lang":462,"seoTitle":836,"titleClass":463,"socialimg":837,"blogtitlepic":838,"customExcerpt":839,"keywords":840,"asideNav":841,"maxContent":473},"Metoder til certifikatregistrering - SCEP, ACME, EST og Microsoft RPC","/blog/heads/header-scepman-enrollment-methods.png","header-scepman-enrollment-methods.png","Få indblik i, hvordan certifikatregistrering fungerer med SCEP, ACME, EST, Microsoft RPC og manuelle metoder. Sammenlign PKI-protokoller til registrering, når certifikater skal udstedes sikkert.","metoder til certifikatregistrering, SCEP, ACME, EST, Microsoft RPC, protokol til certifikatregistrering, certifikatregistrering i PKI, enrollment over secure transport, Simple Certificate Enrollment Protocol, Automatic Certificate Management Environment, certifikatregistrering med Microsoft",{"menuItems":842},[843,845],{"href":844,"text":499},"#scep",{"href":846,"text":748},"#microsoft-rpcdcom","/glossary/enrollment-methods",{"title":480,"description":485},"glossary/enrollment-methods","pMZdwdIy2PbJXkJkEvnKTmCcvFi_YmgaFbZQ2tPJGM0",{"id":852,"title":853,"author":143,"body":854,"cta":143,"description":435,"eventid":143,"extension":458,"hideInRecent":459,"layout":460,"meta":1088,"moment":143,"navigation":473,"path":1106,"seo":1107,"stem":1108,"tags":143,"webcast":459,"__hash__":1109},"content_da/glossary/important-data-formats.md","Vigtige dataformater",{"type":145,"value":855,"toc":1071},[856,860,879,886,889,893,897,900,903,906,910,913,917,920,923,931,934,938,946,949,952,955,966,970,983,987,990,993,996,999,1007,1011,1014,1017,1020,1031,1035,1038,1042,1050,1054,1062,1065],[148,857,859],{"id":858},"x509","X.509",[153,861,862,863,866,867,872,873,878],{},"X.509 er ",[671,864,865],{},"dén"," standard for digitale certifikater. Der har været konkurrenter som ",[242,868,871],{"href":869,"rel":870},"https://www.rfc-editor.org/rfc/rfc4880",[624],"OpenPGP",", men de bruges langt sjældnere i dag. Men vent ... X.509 er faktisk ikke den rigtige standard. X.509 er en ITU-T-standard, mens de definitioner, der reelt betyder noget, er en del af ",[242,874,877],{"href":875,"rel":876},"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 til internettet\" med udgangspunkt i X.509, og det er den eneste profil, der har reel betydning i praksis.",[153,880,881,882,885],{},"Et digitalt certifikat bygger på asymmetrisk kryptografi og især på digitale signaturer. Det mest almindelige formål med digitale certifikater i dag er serverautentificering. Alle har allerede brugt dem, formentlig uden at vide, at der var tale om et X.509-certifikat: Hver gang du åbner et HTTP",[157,883,884],{},"S","-websted, opretter browseren en TLS-forbindelse til webserveren. Webserveren bruger et X.509-certifikat til at bevise, hvem den er. Når folk for eksempel åbner deres banks websted for at overføre penge fra deres konto, vil de gerne være sikre på, at det rent faktisk er banken, de kommunikerer med. Angribere kan forsøge at udgive sig for bankens websted, læse brugerens adgangskode og TAN-kode og derefter overføre pengene til en konto, de selv kontrollerer. HTTPS er med til at forhindre det, fordi angriberne ikke har X.509-certifikatet fra bankens webserver. Når browseren siger, at du er inde på et bestemt domæne, og at forbindelsen er HTTPS, sikrer certifikatet, at du rent faktisk er forbundet til en webserver, der tilhører ejeren af domænet.",[153,887,888],{},"Hvordan gør certifikatet det? Certifikatet indeholder nogle metadata, den offentlige nøgle fra et kryptografisk nøglepar og en signatur fra en certifikatmyndighed. Lad os gennemgå de tre dele:",[165,890,892],{"id":891},"indholdet-i-et-x509-certifikat","Indholdet i et X.509-certifikat",[410,894,896],{"id":895},"metadata","Metadata",[153,898,899],{},"Metadataene i X.509-certifikatet angiver blandt andet, i hvilket tidsrum certifikatet er gyldigt, hvad det må bruges til, og hvem det er udstedt til. Særligt for et TLS-servercertifikat indeholder de webserverens domæne. Browseren sammenligner det domæne, den forsøgte at åbne, med domænet i certifikatet. Hvis de ikke stemmer overens, fortsætter browseren ikke, men viser en advarsel. Hvis certifikatet er udløbet, viser den også en advarsel.",[153,901,902],{},"Mærkeligt nok viste browsere ofte ingen advarsel, hvis du åbnede et HTTP-websted uden TLS, selvom det er endnu mindre sikkert. Hvis du åbnede en webserver med et ugyldigt X.509-certifikat, kunne der være tale om en fejlkonfiguration, og du kunne godt være beskyttet mod angribere, der udspionerer din forbindelse, mens HTTP-forbindelsen slet ingen beskyttelse giver.",[153,904,905],{},"Der er dog sket fremskridt på området, for eksempel Certificate Pinning. Men det er et emne for viderekomne, så lad os se på de to andre ting i et X.509-certifikat.",[410,907,909],{"id":908},"offentlig-nøgle","Offentlig nøgle",[153,911,912],{},"Certifikatet indeholder den offentlige del af et asymmetrisk nøglepar. Kryptografien gør det muligt for webserveren, eller mere generelt for certifikatindehaveren i andre anvendelser, at bevise, at den også har den private del af nøgleparret, uden at afsløre den over for den klient, der opretter forbindelse, eller over for andre. Dermed kan klienten være sikker på, at webserveren rent faktisk ejer certifikatet og ikke bare har kopieret det. Selve certifikatet er faktisk ret nemt at kopiere, fordi webserveren sender en kopi af det til alle, der forsøger at forbinde til serveren. Det er svært eller umuligt at stjæle den private nøgle, fordi den aldrig forlader webserveren. Der findes forskellige metoder til at gøre tyveri af den private nøgle endnu sværere, for eksempel HSM'er og TPM'er.",[410,914,916],{"id":915},"signatur-fra-en-certifikatmyndighed","Signatur fra en certifikatmyndighed",[153,918,919],{},"Metadataene gør det muligt for klienten at kontrollere, at certifikatet passer til det konkrete formål. Den offentlige nøgle viser, at modparten rent faktisk ejer certifikatet. Men en angriber kunne jo bare danne et nyt nøglepar og et nyt certifikat, der også opfylder de to kriterier. Hvordan skulle en klient vide, om certifikatet er troværdigt?",[153,921,922],{},"Certifikatet indeholder en kryptografisk signatur fra et andet nøglepar, som hører til et certifikat fra en certifikatmyndighed (CA). CA-certifikatet kan kontrolleres på samme måde og er også signeret af et certifikat. Klienten kan følge denne tillidskæde fra det såkaldte bladcertifikat op til Root CA-certifikatet, som den kan genkende på, at det er selvsigneret, altså at certifikatets signatur stammer fra dets eget nøglepar. Normalt er det kun et eller to trin, så der er kun et eller to CA-certifikater involveret.",[153,924,925,926,930],{},"CA'er skal omhyggeligt kontrollere, at metadataene er korrekte, når de ",[242,927,929],{"href":928},"enrollment-methods/","udsteder et certifikat",". Hvis du for eksempel vil have et TLS-servercertifikat til dit eget domæne, skal du bevise over for CA'en, at du rent faktisk er ejeren. Alt efter hvor grundig den kontrol er, får du et almindeligt certifikat eller et Extended Validation-certifikat (EV).",[153,932,933],{},"Hver browser og hvert styresystem leveres med en liste over foruddefinerede betroede Root CA'er. Brugere og administratorer kan tilføje flere betroede Root CA'er. Nogle Root CA'er er kun betroede til bestemte formål, mens andre har en mere generel tillid. Klienten kontrollerer, om tillidskæden ender i en betroet Root CA. Hvis den gør det, og alle certifikater i tillidskæden stadig er gyldige, og metadataene siger, at de bruges efter deres formål, er webserverens bladcertifikat betroet, og forbindelsen bliver oprettet.",[165,935,937],{"id":936},"gyldighed-af-x509-certifikater","Gyldighed af X.509-certifikater",[153,939,940,941,945],{},"X.509-certifikater handler om tillid, der skal etableres. Som forklaret er et kriterium for tillid, at et certifikat kan føres op til en betroet Root CA. Et andet er, at det er inden for sin gyldighedsperiode. Det betyder som regel, at det ikke er udløbet, men et certifikat kan også nå at være endnu ikke gyldigt, typisk på grund af tekniske fejl. Der er dog et kriterium mere: CA'en, der udstedte certifikatet, må ikke have tilbagekaldt det. Fordi det er et emne for sig, har vi en ",[242,942,944],{"href":943},"other-stuff/certificate-lifecycle-management","separat artikel"," om det.",[148,947,637],{"id":948},"pkcs7",[153,950,951],{},"PKCS#7 er schweizerkniven blandt kryptografiske dataformater, og det kan indeholde stort set hvad som helst: krypterede beskeder, signerede beskeder, signerede og krypterede beskeder, certifikater og private nøgler",[153,953,954],{},"Det er samtidig formatets største ulempe. Når en applikation eller en bruger får en PKCS#7, fremgår det ikke i sig selv, hvad der skal gøres med den. Her er nogle vigtige anvendelser:",[172,956,957,960,963],{},[175,958,959],{},"S/MIME-beskeder er grundlæggende e-mails med PKCS#7 som brødtekst eller vedhæftet fil.",[175,961,962],{},"SCEP-anmodninger og -svar er begge reelt signerede PKCS#7-beskeder.",[175,964,965],{},"EST-svar er CMS-beskeder.",[165,967,969],{"id":968},"kodning","Kodning",[153,971,972,973,977,978,982],{},"Almindelige filendelser er .p7b (",[242,974,976],{"href":975},"asn.1-and-pem#der-encoding","DER-kodet","), .p7s (en signeret besked eller en beskedsignatur) og .p7m (en signeret og/eller krypteret besked). ",[242,979,981],{"href":980},"asn.1-and-pem#pem-encoding","PEM-kodningen"," med label \"PKCS7\" er også defineret, men bruges sjældent.",[165,984,986],{"id":985},"værktøjer","Værktøjer",[153,988,989],{},"I Windows kan du åbne PKCS#7-beskeder med et dobbeltklik, hvorefter Crypto-shell-udvidelserne viser dem for dig. Du kan dog som regel kun udtrække certifikater og deres private nøgler, ikke beskedindholdet.",[153,991,992],{},"Du kan konvertere filerne til andre formater med værktøjer som OpenSSL.",[148,994,642],{"id":995},"pkcs10",[153,997,998],{},"En Certificate Signing Request (CSR), som defineret i PKCS#10, er en fil med en beskrivelse af det certifikat, du gerne vil have fra en certifikatmyndighed (CA). Den har en struktur, der ligner et X.509-certifikat, men den mangler signaturen fra en CA. Til gengæld indeholder den signaturen fra den, der anmoder om certifikatet. Det er stadig et andet format, så det er ikke det samme som et selvsigneret certifikat.",[153,1000,1001,1002,648],{},"Den kan være binært DER-kodet eller PEM-kodet ",[242,1003,1006],{"href":1004,"rel":1005},"https://datatracker.ietf.org/doc/html/rfc7468#section-7",[624],"med labelen \"CERTIFICATE REQUEST\"",[148,1008,1010],{"id":1009},"pkcs12","PKCS#12",[153,1012,1013],{},"PKCS#12 kaldes også PFX, især i Windows-miljøer. Almindelige filendelser er derfor .pfx og .p12. Formatet indeholder X.509-certifikater og næsten altid de tilhørende private nøgler, selvom det teknisk set ikke er et krav.",[153,1015,1016],{},"Data i en PKCS#12-fil er som regel krypteret med adgangskoder. Ofte er det kun den private nøgle, der er krypteret, så du kan udtrække certifikaterne uden at kende adgangskoderne, hvis din applikation tillader det, og det gør de færreste. PKCS#12 er den mest udbredte måde at gemme et certifikat og dets private nøgle i en fil på i Windows-miljøer. I Linux-miljøer er PEM-kodede PKCS#8-filer mere almindelige.",[153,1018,1019],{},"Fordi standarden giver mange muligheder for at gemme certifikater og private nøgler i indlejrede safebags, har PKCS#12-filer nogle kompatibilitetsproblemer, for eksempel:",[172,1021,1022,1025,1028],{},[175,1023,1024],{},"Windows er berygtet for at knytte private nøgler i en PKCS#12 til alle certifikater, der udtrækkes fra filen, og ikke kun til det, nøglen hører til. Hvis PKCS#12-filen indeholder en certifikatkæde, kan Windows finde på at vise, at den har den private nøgle til CA-certifikatet.",[175,1026,1027],{},"På macOS kan du ikke importere PKCS#12-filer, hvis de kryptografiske algoritmer er for nye.",[175,1029,1030],{},"Det kan være nødvendigt at kryptere certifikaterne i en PKCS#12-fil, for at de modtagende applikationer kan udtrække dem. Men nogle understøtter kun meget gamle og svage algoritmer, hvilket normalt ikke er et problem, eftersom oplysningerne alligevel er offentlige. OpenSSL 3.x understøtter dog ikke disse gamle og sårbare algoritmer og nægter at åbne PKCS#12-filen.",[148,1032,1034],{"id":1033},"asn1-og-pem","ASN.1 og PEM",[153,1036,1037],{},"Abstract Syntax Notation One (ASN.1) er et sprog, der bruges til at beskrive datastrukturer. Der findes nogle foruddefinerede basisdatatyper som heltal og sekvenser, og den, der udvikler en protokol eller et filformat, kan derefter definere egne datatyper ud fra de grundlæggende.",[165,1039,1041],{"id":1040},"der-kodning","DER-kodning",[153,1043,1044,1049],{},[242,1045,1048],{"href":1046,"rel":1047},"https://www.itu.int/rec/T-REC-X.680/",[624],"ITU-T-standarden X.680"," definerer forskellige kodninger af data, der er specificeret som ASN.1. For X.509-relaterede data er den vigtigste kodning DER, fordi der kun findes én måde at kode en type på. Derfor vil en hash af den binære DER-repræsentation af typen altid have den samme værdi, og det er vigtigt, for eksempel når ASN.1-kodede data skal signeres.",[165,1051,1053],{"id":1052},"pem-kodning","PEM-kodning",[153,1055,1056,1057,1061],{},"For mange, men ikke alle X.509-relaterede filtyper kan du enten gemme filen binært i DER-kodning eller lægge en ekstra ",[242,1058,1053],{"href":1059,"rel":1060},"https://datatracker.ietf.org/doc/html/rfc7468",[624]," oven på DER-kodningen. PEM bruger kun ASCII-tegn og kan derfor nemt kopieres og indsættes via udklipsholderen eller, for nogle årtier siden, da det stadig var relevant, sendes med e-mail.",[165,1063,986],{"id":1064},"værktøjer-1",[153,1066,1067,1068,648],{},"Hvis du har en ASN.1-kodet fil, og du enten ikke ved, hvilken type det er, eller ikke har en applikation, der håndterer den konkrete type, kan du stadig afkode den rå ASN.1-struktur og se, hvad den indeholder. I Windows kan det indbyggede værktøj certutil gøre det med kommandoen ",[805,1069,1070],{},"certutil -decode",{"title":435,"searchDepth":436,"depth":436,"links":1072},[1073,1077,1081,1082,1083],{"id":858,"depth":436,"text":859,"children":1074},[1075,1076],{"id":891,"depth":441,"text":892},{"id":936,"depth":441,"text":937},{"id":948,"depth":436,"text":637,"children":1078},[1079,1080],{"id":968,"depth":441,"text":969},{"id":985,"depth":441,"text":986},{"id":995,"depth":436,"text":642},{"id":1009,"depth":436,"text":1010},{"id":1033,"depth":436,"text":1034,"children":1084},[1085,1086,1087],{"id":1040,"depth":441,"text":1041},{"id":1052,"depth":441,"text":1053},{"id":1064,"depth":441,"text":986},{"lang":462,"seoTitle":1089,"titleClass":463,"blogtitlepic":1090,"socialimg":1091,"customExcerpt":1092,"keywords":1093,"asideNav":1094,"maxContent":473},"Vigtige dataformater - X.509, PKCS, ASN.1 og PEM forklaret","header-scepman-important-data-formats.png","/blog/heads/header-scepman-important-data-formats.png","Få overblik over de vigtigste kryptografi- og certifikatformater, blandt andet X.509, PKCS 7, PKCS 10, PKCS 12, ASN.1 og PEM.","vigtige dataformater, X.509-certifikat, PKCS-formater, PKCS 7, PKCS 10, PKCS 12, ASN.1, PEM-format, digitale certifikater, public key infrastructure, PKI-formater",{"menuItems":1095},[1096,1098,1100,1102,1104],{"href":1097,"text":859},"#x509",{"href":1099,"text":637},"#pkcs7",{"href":1101,"text":642},"#pkcs10",{"href":1103,"text":1010},"#pkcs12",{"href":1105,"text":1034},"#asn1-og-pem","/glossary/important-data-formats",{"title":853,"description":435},"glossary/important-data-formats","pPHomXOhmMs02bVAdy52N0iWmoOTy-02W1adORfSkfY",{"id":1111,"title":1112,"author":143,"body":1113,"cta":143,"description":435,"eventid":143,"extension":458,"hideInRecent":459,"layout":460,"meta":1336,"moment":143,"navigation":473,"path":1342,"seo":1343,"stem":1344,"tags":143,"webcast":459,"__hash__":1345},"content_da/glossary/public-key-infrastructure.md","Public Key Infrastructure",{"type":145,"value":1114,"toc":1325},[1115,1119,1127,1130,1162,1166,1169,1173,1176,1206,1209,1213,1216,1236,1239,1243,1250,1264,1269,1283,1287,1292,1305,1310,1322],[148,1116,1118],{"id":1117},"etablering-af-tillid","Etablering af tillid",[165,1120,1122,1123,1126],{"id":1121},"hvordan-angiver-en-klient-sin-tillid-til-en-bestemt-root-ca","Hvordan ",[157,1124,1125],{},"angiver"," en klient sin tillid til en bestemt Root CA?",[153,1128,1129],{},"En klient tilkendegiver sin tillid til en bestemt Root CA (Certificate Authority) gennem en proces, der involverer certifikaternes tillidskæde. Sådan fungerer det:",[172,1131,1132,1138,1144,1150,1156],{},[175,1133,1134,1137],{},[157,1135,1136],{},"Forudinstallerede rodcertifikater:"," De fleste styresystemer og webbrowsere leveres med en række forudinstallerede rodcertifikater fra betroede CA'er. Disse rodcertifikater gemmes i et lager med betroede rodcertifikater.",[175,1139,1140,1143],{},[157,1141,1142],{},"Validering af certifikatet:"," Når en klient forbinder til en server, for eksempel ved besøg på et websted, fremviser serveren sit TLS-certifikat. Certifikatet er typisk signeret af en Intermediate CA, som igen er signeret af en Root CA.",[175,1145,1146,1149],{},[157,1147,1148],{},"Verifikation af tillidskæden:"," Klienten verificerer tillidskæden ved at kontrollere, om det fremviste certifikat er signeret af en betroet Root CA. Den kontrollerer også, om de Intermediate CA'er, der indgår i kæden, er betroede.",[175,1151,1152,1155],{},[157,1153,1154],{},"Digitale signaturer:"," Hvert certifikat i kæden er digitalt signeret af den CA, der ligger over det. Klienten bruger CA'ens offentlige nøgle til at verificere signaturerne og dermed sikre, at certifikaterne ikke er blevet manipuleret.",[175,1157,1158,1161],{},[157,1159,1160],{},"Beslutning om tillid:"," Hvis hele tillidskæden er gyldig og fører tilbage til en betroet Root CA, stoler klienten på serverens certifikat. Dermed kan den sikre kommunikation fortsætte.",[165,1163,1165],{"id":1164},"hvad-er-fordelen-ved-intermediate-caer-frem-for-en-enkelt-root-ca","Hvad er fordelen ved Intermediate CA'er frem for en enkelt Root CA?",[153,1167,1168],{},"For infrastruktur-PKI'er kan en enkelt Root faktisk være en fordel.",[165,1170,1172],{"id":1171},"hvordan-får-en-intermediate-ca-sit-certifikat","Hvordan får en Intermediate CA sit certifikat?",[153,1174,1175],{},"En Intermediate CA (Certificate Authority) får sit certifikat gennem en proces, der kaldes krydssignering af en Root CA. Sådan fungerer det:",[258,1177,1178,1184,1190,1195,1200],{},[175,1179,1180,1183],{},[157,1181,1182],{},"Certificate Signing Request (CSR):"," Den organisation, der vil oprette en Intermediate CA, genererer en CSR. Denne CSR indeholder den offentlige nøgle og identitetsoplysningerne for den Intermediate CA.",[175,1185,1186,1189],{},[157,1187,1188],{},"Indsendelse til Root CA'en:"," CSR'en indsendes til en betroet Root CA.",[175,1191,1192,1194],{},[157,1193,362],{}," Root CA'en verificerer identiteten og legitimiteten af den organisation, der anmoder om det mellemliggende certifikat.",[175,1196,1197,1199],{},[157,1198,350],{}," Når verifikationen er gennemført, bruger Root CA'en sin private nøgle til at signere CSR'en og danner dermed det mellemliggende certifikat. Det signerede certifikat knytter den Intermediate CA til Root CA'en og etablerer en tillidskæde.",[175,1201,1202,1205],{},[157,1203,1204],{},"Udstedelse:"," Root CA'en udsteder det signerede mellemliggende certifikat til den organisation, der har anmodet om det, og organisationen kan derefter bruge det til at signere slutentitetscertifikater, for eksempel TLS-certifikater til websteder.",[153,1207,1208],{},"Processen sikrer, at der er tillid til den Intermediate CA i kraft af dens forbindelse til Root CA'en, som browsere og styresystemer allerede har tillid til.",[165,1210,1212],{"id":1211},"hvad-er-en-certifikatkæde-og-hvordan-fungerer-den","Hvad er en certifikatkæde, og hvordan fungerer den?",[153,1214,1215],{},"En certifikatkæde, også kaldet en tillidskæde, er en række certifikater, der sikrer, at et digitalt certifikat er ægte og troværdigt. Sådan fungerer det:",[172,1217,1218,1224,1230],{},[175,1219,1220,1223],{},[157,1221,1222],{},"Verifikationsprocessen:"," Når en klient, for eksempel en webbrowser, forbinder til en server, fremviser serveren sit slutentitetscertifikat. Klienten kontrollerer derefter certifikatkæden for at sikre, at hvert certifikat er signeret af det næste certifikat i kæden, hele vejen op til rodcertifikatet.",[175,1225,1226,1229],{},[157,1227,1228],{},"Tillidskæden:"," Hvert certifikat i kæden verificeres med den offentlige nøgle fra certifikatet over det. Processen fortsætter op til rodcertifikatet, som klienten allerede har tillid til.",[175,1231,1232,1235],{},[157,1233,1234],{},"Etablering af tillid:"," Hvis hele kæden er gyldig og fører tilbage til et betroet rodcertifikat, stoler klienten på slutentitetscertifikatet, og den sikre kommunikation kan fortsætte.",[153,1237,1238],{},"Systemet sikrer, at slutentitetscertifikatet er legitimt og udstedt af en betroet myndighed, og det opretholder integriteten og sikkerheden i den digitale kommunikation.",[165,1240,1242],{"id":1241},"hvilket-problem-forsøger-udvidelsen-basic-constraints-at-løse","Hvilket problem forsøger udvidelsen Basic Constraints at løse?",[153,1244,1245,1246,1249],{},"Udvidelsen ",[157,1247,1248],{},"Basic Constraints"," i et digitalt certifikat løser problemet med at skelne mellem forskellige typer certifikater og deres roller i en Public Key Infrastructure (PKI). Sådan fungerer det:",[172,1251,1252,1258],{},[175,1253,1254,1257],{},[157,1255,1256],{},"Identifikation af certifikatmyndighed (CA):"," Den angiver, om et certifikat er et CA-certifikat eller et slutentitetscertifikat. Den skelnen er afgørende, fordi CA-certifikater kan udstede andre certifikater, mens slutentitetscertifikater ikke kan.",[175,1259,1260,1263],{},[157,1261,1262],{},"Begrænsning af stilængde:"," Den kan begrænse antallet af Intermediate CA'er, der må ligge under denne CA i certifikatkæden. Det er med til at forhindre alt for lange certifikatkæder, som kan være ineffektive og potentielt usikre.",[153,1265,1266],{},[157,1267,1268],{},"Problemer, der løses:",[172,1270,1271,1277],{},[175,1272,1273,1276],{},[157,1274,1275],{},"Forhindrer uautoriseret udstedelse af certifikater:"," Ved tydeligt at markere hvilke certifikater der må fungere som CA'er, forhindrer udvidelsen, at slutentitetscertifikater udsteder andre certifikater, og den opretholder dermed integriteten i PKI'en.",[175,1278,1279,1282],{},[157,1280,1281],{},"Styring af certifikatkædens længde:"," Begrænsningen af stilængden sikrer, at certifikatkæden forbliver håndterbar og sikker, og den forebygger potentielle sårbarheder ved lange kæder",[165,1284,1286],{"id":1285},"hvilke-mekanismer-bruger-den-til-at-løse-problemerne"," Hvilke mekanismer bruger den til at løse problemerne?",[153,1288,1245,1289,1291],{},[157,1290,1248],{}," i et digitalt certifikat bruger følgende mekanismer til at løse problemerne med at skelne CA-certifikater fra slutentitetscertifikater og styre certifikatkædens længde:",[172,1293,1294,1300],{},[175,1295,1296,1299],{},[157,1297,1298],{},"CA-flaget:"," Flaget angiver, om certifikatet er et CA-certifikat (Certificate Authority) eller et slutentitetscertifikat. Hvis flaget er sat til TRUE, kan certifikatet bruges til at signere andre certifikater, og det er dermed et CA-certifikat. Hvis det er sat til FALSE, er det et slutentitetscertifikat, som ikke kan udstede andre certifikater.",[175,1301,1302,1304],{},[157,1303,1262],{}," Den angiver det maksimale antal mellemliggende certifikater, der ikke er selvudstedte, og som må følge efter dette certifikat i en gyldig certificeringssti. Med den begrænsning sætter udvidelsen en grænse for certifikatkædens længde og sikrer, at den forbliver håndterbar og sikker.",[153,1306,1307],{},[157,1308,1309],{},"Sådan fungerer mekanismerne:",[172,1311,1312,1317],{},[175,1313,1314,1316],{},[157,1315,1298],{}," Når et certifikat udstedes, sættes CA-flaget efter certifikatets tilsigtede brug. Under valideringen af certifikatet kontrollerer klienter flaget for at afgøre, om certifikatet kan betros til at udstede andre certifikater.",[175,1318,1319,1321],{},[157,1320,1262],{}," Værdien kontrolleres under valideringen for at sikre, at certifikatkæden ikke overskrider den angivne længde. Hvis kæden er for lang, betragtes certifikatet som ugyldigt.",[153,1323,1324],{},"Mekanismerne er med til at opretholde integriteten og sikkerheden i en Public Key Infrastructure (PKI), fordi de sikrer, at kun autoriserede certifikater kan udstede andre certifikater, og fordi de forhindrer alt for lange certifikatkæder.",{"title":435,"searchDepth":436,"depth":436,"links":1326},[1327],{"id":1117,"depth":436,"text":1118,"children":1328},[1329,1331,1332,1333,1334,1335],{"id":1121,"depth":441,"text":1330},"Hvordan angiver en klient sin tillid til en bestemt Root CA?",{"id":1164,"depth":441,"text":1165},{"id":1171,"depth":441,"text":1172},{"id":1211,"depth":441,"text":1212},{"id":1241,"depth":441,"text":1242},{"id":1285,"depth":441,"text":1286},{"lang":462,"seoTitle":1337,"titleClass":463,"socialimg":1338,"blogtitlepic":1339,"customExcerpt":1340,"keywords":1341,"maxContent":473},"Etablering af tillid i Public Key Infrastructure: PKI-tillidsmodellen for certifikater","/blog/heads/header-scepman-public-key-infrastructure.png","header-scepman-public-key-infrastructure.png","Etabler tillid i din PKI med certifikatkæder, Root CA og Intermediate CA samt sikker validering af certifikater.","etablering af tillid i PKI, tillid i public key infrastructure, certifikaternes tillidskæde, tillid til Root CA, tillid til Intermediate CA, PKI-tillidsmodel, validering af certifikater, betroede rodcertifikater, sikker verifikation af certifikater, verifikation af tillidskæden","/glossary/public-key-infrastructure",{"title":1112,"description":435},"glossary/public-key-infrastructure","mY3jJpqY5tvW1XZgImoIYWckHAf_LYqYkkYCxWBZxTA",{"id":1347,"title":1348,"author":143,"body":1349,"cta":143,"description":435,"eventid":143,"extension":458,"hideInRecent":459,"layout":460,"meta":1788,"moment":143,"navigation":473,"path":1794,"seo":1795,"stem":1796,"tags":143,"webcast":459,"__hash__":1797},"content_da/glossary/use-cases-for-certificates.md","Anvendelser af certifikater",{"type":145,"value":1350,"toc":1773},[1351,1355,1359,1373,1377,1409,1413,1444,1448,1454,1460,1464,1517,1521,1525,1539,1543,1555,1559,1562,1576,1580,1586,1597,1602,1613,1619,1630,1634,1654,1658,1661,1665,1685,1689,1706,1711,1731,1735,1738,1770],[148,1352,1354],{"id":1353},"transport-layer-security-tls","Transport Layer Security (TLS)",[165,1356,1358],{"id":1357},"hvilke-to-spørgsmål-skal-en-klient-stille-når-den-modtager-et-certifikat-fra-en-server","Hvilke to spørgsmål skal en klient stille, når den modtager et certifikat fra en server?",[258,1360,1361,1367],{},[175,1362,1363,1366],{},[157,1364,1365],{},"Er certifikatet gyldigt og betroet?"," Klienten skal verificere, at certifikatet er udstedt af en betroet certifikatmyndighed (CA), og at det hverken er udløbet eller tilbagekaldt. Det indebærer at kontrollere certifikatets gyldighedsperiode og at sikre, at det er signeret af en CA, som klienten har tillid til.",[175,1368,1369,1372],{},[157,1370,1371],{},"Stemmer certifikatet overens med serverens identitet?"," Klienten skal sikre, at oplysningerne i certifikatet, for eksempel Common Name (CN) eller Subject Alternative Name (SAN), svarer til serverens domænenavn. Det er med til at bekræfte, at certifikatet rent faktisk er tiltænkt den server, klienten forsøger at forbinde til.",[165,1374,1376],{"id":1375},"hvordan-validerer-klienten-at-et-certifikat-kan-betros","Hvordan validerer klienten, at et certifikat kan betros?",[258,1378,1379,1385,1391,1397,1403],{},[175,1380,1381,1384],{},[157,1382,1383],{},"Kontroller certifikaternes tillidskæde:"," Klienten verificerer certifikatkæden, der består af serverens certifikat, eventuelle mellemliggende certifikater og rodcertifikatet. Hvert certifikat i kæden skal være signeret af den næste myndighed i rækken, så kæden til sidst fører til et betroet rodcertifikat.",[175,1386,1387,1390],{},[157,1388,1389],{},"Verificer certifikatets gyldighedsperiode:"," Klienten kontrollerer certifikatets gyldighedsperiode for at sikre, at det hverken er udløbet eller endnu ikke gyldigt. Det indebærer at kontrollere datoerne \"Not Before\" og \"Not After\" i certifikatet.",[175,1392,1393,1396],{},[157,1394,1395],{},"Match certifikatet med serverens identitet:"," Klienten sikrer, at certifikatets Common Name (CN) eller Subject Alternative Name (SAN) svarer til serverens domænenavn. Det bekræfter, at certifikatet er tiltænkt den server, klienten forbinder til.",[175,1398,1399,1402],{},[157,1400,1401],{},"Kontroller for tilbagekaldelse:"," Klienten kontrollerer, om certifikatet er tilbagekaldt, ved at forespørge Certificate Revocation List (CRL) eller ved at bruge Online Certificate Status Protocol (OCSP). Et tilbagekaldt certifikat er ikke længere betroet.",[175,1404,1405,1408],{},[157,1406,1407],{},"Verificer den digitale signatur:"," Klienten verificerer den digitale signatur på certifikatet for at sikre, at det ikke er blevet manipuleret. Det indebærer at kontrollere den kryptografiske signatur mod den udstedende CA's offentlige nøgle.",[165,1410,1412],{"id":1411},"hvordan-validerer-klienten-at-serveren-rent-faktisk-ejer-certifikatet","Hvordan validerer klienten, at serveren rent faktisk ejer certifikatet?",[258,1414,1415,1421,1427,1433,1439],{},[175,1416,1417,1420],{},[157,1418,1419],{},"Verifikation af certifikatkæden:"," Klienten verificerer certifikatkæden og sikrer, at hvert certifikat i kæden er signeret af en betroet certifikatmyndighed (CA). Kæden starter ved serverens certifikat og slutter ved et betroet rodcertifikat.",[175,1422,1423,1426],{},[157,1424,1425],{},"Match af domænenavn:"," Klienten kontrollerer, at certifikatets Common Name (CN) eller Subject Alternative Name (SAN) svarer til serverens domænenavn. Det sikrer, at certifikatet er tiltænkt den server, klienten forbinder til.",[175,1428,1429,1432],{},[157,1430,1431],{},"Verifikation af den digitale signatur:"," Klienten verificerer den digitale signatur på certifikatet med den udstedende CA's offentlige nøgle. Det sikrer, at certifikatet ikke er blevet manipuleret, og at det rent faktisk er udstedt af en betroet CA.",[175,1434,1435,1438],{},[157,1436,1437],{},"Certifikatets gyldighedsperiode:"," Klienten kontrollerer certifikatets gyldighedsperiode for at sikre, at det er gyldigt netop nu og ikke er udløbet.",[175,1440,1441,1402],{},[157,1442,1443],{},"Kontrol af tilbagekaldelsesstatus:",[165,1445,1447],{"id":1446},"hvorfor-er-ejerskab-vigtigt-når-du-allerede-har-kontrolleret-at-certifikatet-er-betroet","Hvorfor er ejerskab vigtigt, når du allerede har kontrolleret, at certifikatet er betroet?",[153,1449,1450,1453],{},[157,1451,1452],{},"Certifikatets gyldighed og tillid:"," Dette trin sikrer, at certifikatet er udstedt af en betroet certifikatmyndighed (CA), at det er inden for sin gyldighedsperiode, og at det ikke er tilbagekaldt. Det bekræfter, at certifikatet er legitimt og ikke er blevet manipuleret.",[153,1455,1456,1459],{},[157,1457,1458],{},"Verifikation af serverens identitet:"," Selv hvis et certifikat er gyldigt og betroet, skal det også bekræftes, at det tilhører den server, du forbinder til. Det indebærer at kontrollere, at certifikatets Common Name (CN) eller Subject Alternative Name (SAN) svarer til serverens domænenavn. Trinnet sikrer, at certifikatet er tiltænkt den konkrete server, og det forhindrer man-in-the-middle-angreb, hvor en angriber kan fremvise et gyldigt certifikat til et andet domæne.",[165,1461,1463],{"id":1462},"hvilke-to-metoder-bruger-klienten-til-at-besvare-spørgsmålet-og-hvilke-to-resultater-kan-hver-metode-give","Hvilke to metoder bruger klienten til at besvare spørgsmålet, og hvilke to resultater kan hver metode give?",[258,1465,1466,1493],{},[175,1467,1468,1471,1472,1475,1478,1479],{},[157,1469,1470],{},"Verifikation via Domain Name System (DNS):"," Klienten kontrollerer, at certifikatets Common Name (CN) eller Subject Alternative Name (SAN) svarer til serverens domænenavn. ",[1473,1474],"br",{},[157,1476,1477],{},"Resultat",":",[172,1480,1481,1487],{},[175,1482,1483,1486],{},[157,1484,1485],{},"Match",": Hvis navnene stemmer overens, kan klienten fortsætte med forbindelsen i tillid til, at certifikatet er tiltænkt serveren. ",[175,1488,1489,1492],{},[157,1490,1491],{},"Uoverensstemmelse",": Hvis navnene ikke stemmer overens, afbryder klienten sandsynligvis forbindelsen eller viser en advarsel om en mulig sikkerhedsrisiko.",[175,1494,1495,1498,1499,1501,1478,1503],{},[157,1496,1497],{},"Verifikation via Public Key Infrastructure (PKI):"," Klienten verificerer den digitale signatur på certifikatet med den udstedende certifikatmyndigheds (CA) offentlige nøgle. ",[1473,1500],{},[157,1502,1477],{},[172,1504,1505,1511],{},[175,1506,1507,1510],{},[157,1508,1509],{},"Gyldig signatur",": Hvis signaturen er gyldig, bekræfter det, at certifikatet ikke er blevet manipuleret, og at det er udstedt af en betroet CA.",[175,1512,1513,1516],{},[157,1514,1515],{},"Ugyldig signatur:"," Hvis signaturen er ugyldig, afbryder klienten forbindelsen eller viser en advarsel om, at certifikatet kan være kompromitteret eller forfalsket.",[165,1518,1520],{"id":1519},"hvad-afgør-hvilken-metode-der-bruges","Hvad afgør, hvilken metode der bruges?",[153,1522,1523],{},[157,1524,1470],{},[172,1526,1527,1533],{},[175,1528,1529,1532],{},[157,1530,1531],{},"Anvendelse",": Metoden bruges altid som en del af TLS-handshaket. Klienten kontrollerer certifikatets Common Name (CN) eller Subject Alternative Name (SAN) mod serverens domænenavn for at sikre, at de stemmer overens.",[175,1534,1535,1538],{},[157,1536,1537],{},"Afgørende faktorer:"," Det er en fast del af TLS-protokollen, og klienten udfører det automatisk, når en sikker forbindelse oprettes.",[153,1540,1541],{},[157,1542,1497],{},[172,1544,1545,1550],{},[175,1546,1547,1549],{},[157,1548,1531],{},": Metoden bruges også altid under TLS-handshaket. Klienten verificerer den digitale signatur på certifikatet med den udstedende certifikatmyndigheds (CA) offentlige nøgle.",[175,1551,1552,1554],{},[157,1553,1537],{}," Det er endnu en fast del af TLS-protokollen. Klienten udfører automatisk kontrollen for at sikre, at certifikatet er gyldigt og ikke er blevet manipuleret.",[148,1556,1558],{"id":1557},"hvilke-certifikater-skal-serveren-sende-til-klienten","Hvilke certifikater skal serveren sende til klienten?",[153,1560,1561],{},"Under TLS-handshaket bør serveren sende følgende certifikater til klienten:",[172,1563,1564,1570],{},[175,1565,1566,1569],{},[157,1567,1568],{},"Slutentitetscertifikatet:"," Det er serverens eget certifikat, som beviser dens identitet over for klienten.",[175,1571,1572,1575],{},[157,1573,1574],{},"Mellemliggende certifikater:"," Certifikaterne forbinder slutentitetscertifikatet med det betroede rodcertifikat. De er med til at etablere en tillidskæde fra serverens certifikat tilbage til et betroet rodcertifikat.",[148,1577,1579],{"id":1578},"hvad-er-domain-validation-og-extended-validation-certifikater","Hvad er Domain Validation- og Extended Validation-certifikater?",[153,1581,1582,1585],{},[157,1583,1584],{},"Domain Validation-certifikater (DV)"," er en type TLS-certifikat, hvor certifikatmyndigheden (CA) verificerer, at ansøgeren har kontrol over domænet. Det sker typisk ved at:",[172,1587,1588,1591,1594],{},[175,1589,1590],{},"Svare på en e-mail sendt til domænets administrative kontakt.",[175,1592,1593],{},"Tilføje en DNS TXT-post.",[175,1595,1596],{},"Uploade en fil til webserveren.",[153,1598,1599],{},[157,1600,1601],{},"Vigtigste kendetegn:",[172,1603,1604,1607,1610],{},[175,1605,1606],{},"Hurtig udstedelse: De kan udstedes hurtigt, ofte i løbet af minutter, fordi de kræver minimal validering.",[175,1608,1609],{},"Grundlæggende sikkerhed: De giver kryptering og en grundlæggende sikkerhed for, at domænet kontrolleres af den enhed, der anmoder om certifikatet.",[175,1611,1612],{},"God økonomi: De er ofte billigere eller helt gratis, og det gør dem tilgængelige for små websteder og private projekter.",[153,1614,1615,1618],{},[157,1616,1617],{},"Extended Validation-certifikater (EV)"," er en højere klasse af TLS-certifikater, der kræver en mere grundig valideringsproces. CA'en verificerer den juridiske, fysiske og operationelle eksistens af den enhed, der anmoder om certifikatet. Det omfatter at:",[172,1620,1621,1624,1627],{},[175,1622,1623],{},"Bekræfte enhedens juridiske identitet og status.",[175,1625,1626],{},"Verificere enhedens fysiske og operationelle tilstedeværelse.",[175,1628,1629],{},"Sikre, at enheden har eneret til at bruge domænet.",[153,1631,1632],{},[157,1633,1601],{},[172,1635,1636,1642,1648],{},[175,1637,1638,1641],{},[157,1639,1640],{},"Høj sikkerhed:"," Giver brugerne den højeste grad af tillid og sikkerhed, fordi processen indebærer en grundig kontrol.",[175,1643,1644,1647],{},[157,1645,1646],{},"Synlige indikatorer:"," I nogle browsere viste EV-certifikater tidligere organisationens navn i adresselinjen, men det er mindre udbredt i dag.",[175,1649,1650,1653],{},[157,1651,1652],{},"Styrket tillid:"," Ideel til websteder, der håndterer følsomme oplysninger, for eksempel finansielle institutioner og e-handelssteder.",[165,1655,1657],{"id":1656},"hvilke-er-mest-sikre"," Hvilke er mest sikre?",[153,1659,1660],{},"Extended Validation-certifikater (EV) anses generelt for mere sikre end Domain Validation-certifikater (DV) på grund af den grundige valideringsproces, de gennemgår. Her er en sammenligning:",[153,1662,1663],{},[157,1664,1584],{},[172,1666,1667,1673,1679],{},[175,1668,1669,1672],{},[157,1670,1671],{},"Valideringsniveau:"," Verificerer kun kontrol over domænet.",[175,1674,1675,1678],{},[157,1676,1677],{},"Sikkerhed:"," Giver grundlæggende kryptering og sikkerhed.",[175,1680,1681,1684],{},[157,1682,1683],{},"Anvendelse:"," Egner sig til private websteder, blogs og små virksomheder.",[153,1686,1687],{},[157,1688,1617],{},[172,1690,1691,1696,1701],{},[175,1692,1693,1695],{},[157,1694,1671],{}," Verificerer den juridiske, fysiske og operationelle eksistens af enheden.",[175,1697,1698,1700],{},[157,1699,1677],{}," Giver en højere grad af tillid og sikkerhed på grund af den grundige kontrol.",[175,1702,1703,1705],{},[157,1704,1683],{}," Ideel til finansielle institutioner, e-handelssteder og alle websteder, der håndterer følsomme oplysninger.",[153,1707,1708],{},[157,1709,1710],{},"Derfor er EV-certifikater mere sikre:",[172,1712,1713,1719,1725],{},[175,1714,1715,1718],{},[157,1716,1717],{},"Grundig kontrol:"," EV-certifikater kræver omfattende validering, og det gør det sværere for ondsindede aktører at få fat i dem.",[175,1720,1721,1724],{},[157,1722,1723],{},"Tillidsindikatorer:"," Selvom det er mindre udbredt i dag, viste EV-certifikater tidligere organisationens navn i browserens adresselinje og gav dermed brugerne en synlig bekræftelse.",[175,1726,1727,1730],{},[157,1728,1729],{},"Højere sikkerhed:"," Den detaljerede verifikationsproces sikrer, at den enhed, der står bag certifikatet, er legitim, og det mindsker risikoen for phishing og andre angreb.",[148,1732,1734],{"id":1733},"hvordan-foregår-tilbagekaldelse-med-ocsp-stapling","Hvordan foregår tilbagekaldelse med OCSP Stapling",[153,1736,1737],{},"OCSP stapling forbedrer den almindelige OCSP-proces ved at reducere svartiden og styrke privatlivets fred. Sådan fungerer det:",[258,1739,1740,1746,1752,1758,1764],{},[175,1741,1742,1745],{},[157,1743,1744],{},"Serveren anmoder om et OCSP-svar:"," Webserveren anmoder med jævne mellemrum OCSP-responderen, en server, der drives af certifikatmyndigheden (CA), om tilbagekaldelsesstatus for sit certifikat. Anmodningen sker i baggrunden og ikke ved hver enkelt klientforbindelse.",[175,1747,1748,1751],{},[157,1749,1750],{},"OCSP-responderen leverer et svar:"," OCSP-responderen sender et signeret OCSP-svar med tidsstempel tilbage med certifikatets status, for eksempel \"good\", \"revoked\" eller \"unknown\". Serveren cacher svaret.",[175,1753,1754,1757],{},[157,1755,1756],{},"TLS-handshake med et staplet svar:"," Når en klient, for eksempel en webbrowser, opretter en forbindelse til serveren, medsender serveren det cachede OCSP-svar i TLS-handshaket. Det kaldes at \"staple\" svaret til handshaket.",[175,1759,1760,1763],{},[157,1761,1762],{},"Klienten verificerer OCSP-svaret:"," Klienten verificerer det staplede OCSP-svar. Da svaret er signeret af CA'en, kan klienten stole på dets gyldighed. Hvis svaret viser, at certifikatet er tilbagekaldt, opretter klienten ikke en sikker forbindelse.",[175,1765,1766,1769],{},[157,1767,1768],{},"Løbende opdateringer:"," Serveren opdaterer fortsat sit cachede OCSP-svar med jævne mellemrum, så den altid har en aktuel status at levere under TLS-handshaket.",[153,1771,1772],{},"Processen mindsker behovet for, at klienter skal sende separate OCSP-anmodninger, og det forbedrer både ydelsen og privatlivets fred.",{"title":435,"searchDepth":436,"depth":436,"links":1774},[1775,1783,1784,1787],{"id":1353,"depth":436,"text":1354,"children":1776},[1777,1778,1779,1780,1781,1782],{"id":1357,"depth":441,"text":1358},{"id":1375,"depth":441,"text":1376},{"id":1411,"depth":441,"text":1412},{"id":1446,"depth":441,"text":1447},{"id":1462,"depth":441,"text":1463},{"id":1519,"depth":441,"text":1520},{"id":1557,"depth":436,"text":1558},{"id":1578,"depth":436,"text":1579,"children":1785},[1786],{"id":1656,"depth":441,"text":1657},{"id":1733,"depth":436,"text":1734},{"lang":462,"seoTitle":1789,"titleClass":463,"socialimg":1790,"blogtitlepic":1791,"customExcerpt":1792,"keywords":1793,"maxContent":473},"Transport Layer Security (TLS): anvendelser og validering af certifikater","/blog/heads/header-scepman-use-cases-certificates.png","header-scepman-use-cases-certificates.png","Beskyt dit websted og dine brugere med TLS-certifikater, der verificerer servere, skaber tillid via certifikatkæder og sikrer krypterede forbindelser.","TLS-certifikater, Transport Layer Security, anvendelser af certifikater, validering af TLS-certifikater, certifikaternes tillidskæde, DV-certifikater, EV-certifikater, serverautentificering, sikre forbindelser, OCSP stapling","/glossary/use-cases-for-certificates",{"title":1348,"description":435},"glossary/use-cases-for-certificates","ZranCexoL8MrDFIDGCBdihvXRjXTPR26wP95bSLIdIU",{"list":139,"authors":143},1790098989992]