[{"data":1,"prerenderedAt":1800},["ShallowReactive",2],{"sc:header-data-it":3,"sc:footer-data-it":101,"glossary-posts-it":138,"content-it-list-c077398beed29":1799},{"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",{"it":10},{"title":11,"url":12,"alt":13},"Home","/it","SCEPman",[15,19,25,31,83,89],{"name":16,"languages":17},"nav-home",{"it":18},{"title":11,"url":12},{"name":20,"languages":21},"pricing",{"it":22},{"title":23,"url":24},"Prezzi","/it/pricing",{"name":26,"languages":27},"partner",{"it":28},{"title":29,"url":30},"Partner","/it/partner",{"name":32,"languages":33,"children":36},"support-hub",{"it":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",{"it":44},{"title":45,"url":46},"Docs","https://docs.scepman.com/",{"name":48,"languages":49},"faq",{"it":50},{"title":51,"url":52},"FAQ","/it/faq",{"name":54,"children":55},"support-hub-group-2",[56,62],{"name":57,"target":42,"languages":58},"support-ticket",{"it":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",{"it":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",{"it":74},{"title":75,"url":76},"Glossario","/it/glossary",{"name":78,"languages":79},"blog",{"it":80},{"title":81,"url":82},"Blog","/it/blog",{"name":84,"languages":85},"events",{"it":86},{"title":87,"url":88},"Eventi","/it/events",{"name":90,"languages":91},"about",{"it":92},{"title":93,"url":94},"Chi siamo","/it/about-us",{"name":96,"languages":97},"contact",{"it":98},{"title":99,"url":100},"support@scepman.com","mailto:support@scepman.com",{"data":102},{"mail":103,"logos":104,"socials":109,"links":122,"linksIt":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,134,136],{"title":124,"url":125,"target":42},{"title":135,"url":128,"target":42},"Note legali",{"title":137,"url":131,"target":42},"Contatti e sedi",[139,477,851,1110,1346],{"id":140,"title":141,"author":142,"body":143,"cta":142,"description":434,"eventid":142,"extension":457,"hideInRecent":458,"layout":459,"meta":460,"moment":142,"navigation":472,"path":473,"seo":474,"stem":475,"tags":142,"webcast":458,"__hash__":476},"content_it/glossary/cryptography.md","Crittografia",null,{"type":144,"value":145,"toc":433},"minimal",[146,151,163,170,198,204,226,230,233,236,245,248,256,295,299,302,306,309,313,316,320,323,326,330,334,337,363,367,370,387,391,394,398,401,405,408,413],[147,148,150],"h2",{"id":149},"quali-sono-i-due-tipi-di-cifratura-basata-su-chiave","Quali sono i due tipi di cifratura basata su chiave?",[152,153,154,155,159,160],"p",{},"I due tipi principali di cifratura basata su chiave sono la ",[156,157,158],"strong",{},"cifratura simmetrica"," e la ",[156,161,162],{},"cifratura asimmetrica.",[164,165,167],"h3",{"id":166},"cifratura-simmetrica",[156,168,169],{},"Cifratura simmetrica",[171,172,173,180,186,192],"ul",{},[174,175,176,179],"li",{},[156,177,178],{},"Uso delle chiavi",": utilizza un'unica chiave sia per cifrare sia per decifrare.",[174,181,182,185],{},[156,183,184],{},"Velocità",": in genere più rapida ed efficiente.",[174,187,188,191],{},[156,189,190],{},"Sicurezza",": la difficoltà principale consiste nel condividere la chiave tra le parti in modo sicuro.",[174,193,194,197],{},[156,195,196],{},"Esempi",": AES (Advanced Encryption Standard), DES (Data Encryption Standard).",[164,199,201],{"id":200},"cifratura-asimmetrica",[156,202,203],{},"Cifratura asimmetrica",[171,205,206,211,216,221],{},[174,207,208,210],{},[156,209,178],{},": utilizza una coppia di chiavi, una chiave pubblica per cifrare e una chiave privata per decifrare.",[174,212,213,215],{},[156,214,184],{},": più lenta rispetto alla cifratura simmetrica, perché i calcoli sono più complessi.",[174,217,218,220],{},[156,219,190],{},": più sicura per la distribuzione delle chiavi, dato che la chiave privata non viene mai condivisa.",[174,222,223,225],{},[156,224,196],{},": RSA (Rivest-Shamir-Adleman), ECC (Elliptic Curve Cryptography).",[164,227,229],{"id":228},"quale-tipo-di-cifratura-è-considerato-più-sicuro","Quale tipo di cifratura è considerato più sicuro?",[152,231,232],{},"Entrambi gli schemi sono considerati sicuri, nel senso che, utilizzando un algoritmo moderno con una lunghezza di chiave sufficiente, nessun computer attuale è in grado di violare la cifratura.",[152,234,235],{},"Quale tipo di cifratura sia preferibile dipende dal caso d'uso, ma molti casi d'uso richiedono la cifratura asimmetrica, perché impiega una coppia di chiavi: una chiave pubblica per cifrare e una chiave privata per decifrare. La chiave privata resta segreta, e questo aumenta la sicurezza, dato che non deve mai essere condivisa.",[164,237,239,240],{"id":238},"quale-tipo-di-cifratura-è-migliore-per-grandi-volumi-di-dati","Quale tipo di cifratura è migliore per grandi volumi di dati? ",[241,242],"a",{"href":243,"id":244},"#which-type-of-encryption-is-better-for-bulk-data","which-type-of-encryption-is-better-for-bulk-data",[152,246,247],{},"La cifratura simmetrica, perché è più veloce.",[164,249,251,252],{"id":250},"come-funziona-in-generale-la-cifratura-ibrida","Come funziona in generale la cifratura ibrida? ",[241,253],{"href":254,"id":255},"#what-is-the-general-process-for-hybrid-encryption","what-is-the-general-process-for-hybrid-encryption",[257,258,259,265,271,277,283,289],"ol",{},[174,260,261,264],{},[156,262,263],{},"Generazione della chiave",": il mittente genera una nuova chiave simmetrica (detta anche chiave di sessione) per cifrare il messaggio vero e proprio.",[174,266,267,270],{},[156,268,269],{},"Cifratura del messaggio",": il mittente utilizza la chiave simmetrica per cifrare il messaggio in chiaro e ottiene un testo cifrato.",[174,272,273,276],{},[156,274,275],{},"Cifratura della chiave",": il mittente cifra quindi la chiave simmetrica con la chiave pubblica del destinatario (cifratura asimmetrica).",[174,278,279,282],{},[156,280,281],{},"Trasmissione",": il mittente invia al destinatario sia il messaggio cifrato (il testo cifrato) sia la chiave simmetrica cifrata.",[174,284,285,288],{},[156,286,287],{},"Decifratura della chiave",": il destinatario utilizza la propria chiave privata per decifrare la chiave simmetrica.",[174,290,291,294],{},[156,292,293],{},"Decifratura del messaggio",": infine il destinatario utilizza la chiave simmetrica decifrata per decifrare il testo cifrato e recuperare il messaggio in chiaro originale.",[147,296,298],{"id":297},"algoritmi-di-hashing","Algoritmi di hashing",[152,300,301],{},"Un algoritmo di hashing è una funzione matematica che converte dati di ingresso di qualsiasi dimensione in una stringa di caratteri di lunghezza fissa, di solito una sequenza di lettere e cifre. Questo risultato è noto come valore hash o digest.",[164,303,305],{"id":304},"che-cosè-una-collisione","Che cos'è una collisione?",[152,307,308],{},"Nell'hashing si ha una collisione quando due dati distinti producono lo stesso valore hash con un algoritmo di hashing. Questo può essere problematico, perché l'obiettivo principale di un algoritmo di hashing è rappresentare in modo univoco dati di ingresso differenti.",[164,310,312],{"id":311},"che-cosè-un-mac","Che cos'è un MAC?",[152,314,315],{},"Message Authentication Code (MAC): in crittografia, un MAC è una breve informazione utilizzata per autenticare un messaggio e garantirne l'integrità. Attesta che il messaggio non è stato alterato e conferma l'identità del mittente.",[164,317,319],{"id":318},"in-che-cosa-un-mac-differisce-da-un-hmac","In che cosa un MAC differisce da un HMAC?",[152,321,322],{},"MAC: termine generale per un codice che verifica integrità e autenticità di un messaggio, utilizzando cifrari a blocchi oppure funzioni di hash.",[152,324,325],{},"HMAC: un tipo specifico di MAC che utilizza una funzione di hash crittografica e una chiave segreta, offrendo proprietà di sicurezza più robuste.",[147,327,329],{"id":328},"crittografia-asimmetrica","Crittografia asimmetrica",[164,331,333],{"id":332},"come-funziona-in-generale-la-firma-di-un-messaggio","Come funziona in generale la firma di un messaggio?",[152,335,336],{},"La firma di un messaggio è un procedimento crittografico utilizzato per verificare l'autenticità e l'integrità di un messaggio.",[257,338,339,345,351,357],{},[174,340,341,344],{},[156,342,343],{},"Creazione dell'hash:"," il mittente genera un'impronta digitale univoca (hash) del messaggio utilizzando una funzione di hash crittografica (ad esempio SHA-256). Questo hash rappresenta in modo univoco il contenuto del messaggio.",[174,346,347,350],{},[156,348,349],{},"Firma:"," il mittente cifra questo hash con la propria chiave privata, creando la firma digitale. In questo modo la firma può essere generata solo da chi ha accesso alla chiave privata del mittente.",[174,352,353,356],{},[156,354,355],{},"Invio:"," la firma digitale viene allegata al messaggio e i due elementi vengono inviati insieme al destinatario. Per la verifica viene fornita anche la chiave pubblica del mittente.",[174,358,359,362],{},[156,360,361],{},"Verifica:"," il destinatario utilizza la chiave pubblica del mittente per decifrare la firma digitale e recuperare l'hash originale. Genera poi un nuovo hash dal messaggio ricevuto e lo confronta con l'hash decifrato. Se coincidono, è confermato che il messaggio non è stato alterato e l'identità del mittente risulta verificata.",[164,364,366],{"id":365},"quali-sono-le-tre-funzioni-della-cifratura-asimmetrica","Quali sono le tre funzioni della cifratura asimmetrica?",[152,368,369],{},"La cifratura asimmetrica, nota anche come crittografia a chiave pubblica, svolge diverse funzioni importanti per la protezione delle comunicazioni e dei dati.",[257,371,372,377,382],{},[174,373,374],{},[156,375,376],{},"Cifratura e decifratura",[174,378,379],{},[156,380,381],{},"Firme digitali",[174,383,384],{},[156,385,386],{},"Scambio di chiavi",[164,388,390],{"id":389},"rsa","RSA",[152,392,393],{},"RSA, abbreviazione di Rivest-Shamir-Adleman, è un crittosistema a chiave pubblica molto diffuso per la trasmissione sicura dei dati. Prende il nome dai suoi inventori, Ronald Rivest, Adi Shamir e Leonard Adleman, che lo hanno presentato nel 1977.",[164,395,397],{"id":396},"diffie-hellman","Diffie-Hellman",[152,399,400],{},"Lo scambio di chiavi Diffie-Hellman è un metodo utilizzato in crittografia per scambiare chiavi crittografiche in modo sicuro su un canale pubblico. È stato sviluppato da Whitfield Diffie e Martin Hellman nel 1976. Lo scopo principale dello scambio di chiavi Diffie-Hellman è consentire a due parti di generare in modo sicuro una chiave segreta condivisa, utilizzabile per cifrare le comunicazioni successive.",[164,402,404],{"id":403},"digital-signature-algorithm-dsa","Digital Signature Algorithm (DSA)",[152,406,407],{},"Il Digital Signature Algorithm (DSA) è un algoritmo crittografico a chiave pubblica utilizzato per generare e verificare firme digitali. È stato proposto dal National Institute of Standards and Technology (NIST) nel 1991 come parte del Digital Signature Standard (DSS).",[409,410,412],"h4",{"id":411},"come-funziona","Come funziona",[257,414,415,421,427],{},[174,416,417,420],{},[156,418,419],{},"Generazione delle chiavi:"," DSA genera una coppia di chiavi: una chiave privata per firmare e una chiave pubblica per la verifica.",[174,422,423,426],{},[156,424,425],{},"Firma",": il mittente utilizza la propria chiave privata per creare una firma digitale su un messaggio. Questa firma è univoca sia per il messaggio sia per la chiave privata.",[174,428,429,432],{},[156,430,431],{},"Verifica",": il destinatario utilizza la chiave pubblica del mittente per verificare l'autenticità della firma e, di conseguenza, l'integrità e l'origine del messaggio.",{"title":434,"searchDepth":435,"depth":435,"links":436},"",2,[437,445,450],{"id":149,"depth":435,"text":150,"children":438},[439,441,442,443,444],{"id":166,"depth":440,"text":169},3,{"id":200,"depth":440,"text":203},{"id":228,"depth":440,"text":229},{"id":238,"depth":440,"text":239},{"id":250,"depth":440,"text":251},{"id":297,"depth":435,"text":298,"children":446},[447,448,449],{"id":304,"depth":440,"text":305},{"id":311,"depth":440,"text":312},{"id":318,"depth":440,"text":319},{"id":328,"depth":435,"text":329,"children":451},[452,453,454,455,456],{"id":332,"depth":440,"text":333},{"id":365,"depth":440,"text":366},{"id":389,"depth":440,"text":390},{"id":396,"depth":440,"text":397},{"id":403,"depth":440,"text":404},"md",false,"post",{"lang":461,"titleClass":462,"blogtitlepic":463,"socialimg":464,"customExcerpt":465,"asideNav":466,"maxContent":472},"it","h1-font-size","header-scepman-cryptography.png","/blog/heads/header-scepman-cryptography.png","La sfida centrale nella registrazione dei certificati è come autenticare il dispositivo o l'utente che richiede il certificato. Con il certificato, l'autorità di certificazione (CA) conferma che il titolare del certificato possiede determinate proprietà e che ne ha verificato l'autenticità",{"menuItems":467},[468,470],{"href":469,"text":298},"#algoritmi-di-hashing",{"href":471,"text":329},"#crittografia-asimmetrica",true,"/glossary/cryptography",{"title":141,"description":434},"glossary/cryptography","0x11VV8N7pw6wDb7vIrMmvq1SZvZNoUNkAyOucsnL6U",{"id":478,"title":479,"author":142,"body":480,"cta":142,"description":484,"eventid":142,"extension":457,"hideInRecent":458,"layout":459,"meta":835,"moment":142,"navigation":472,"path":847,"seo":848,"stem":849,"tags":142,"webcast":458,"__hash__":850},"content_it/glossary/enrollment-methods.md","Metodi di registrazione dei certificati",{"type":144,"value":481,"toc":822},[482,485,488,491,520,610,612,616,626,630,648,651,654,658,661,664,687,691,694,697,710,714,717,720,723,726,729,732,741,744,748,752,755,761,765,774,777,780,783,800,812,815,818],[152,483,484],{},"Una proprietà fondamentale dei protocolli di registrazione dei certificati è quindi il modo in cui autenticano chi richiede il certificato. A seconda dell'uso previsto per il certificato, risulta più vantaggioso l'uno o l'altro protocollo.",[152,486,487],{},"Un'altra proprietà importante è la diffusione pratica. Il metodo o il protocollo di registrazione deve essere supportato sia dalla CA sia sul lato client per il caso d'uso previsto.",[152,489,490],{},"I protocolli di registrazione più diffusi sono:",[171,492,493,499,502,505,511,514,517],{},[174,494,495],{},[241,496,498],{"href":497},"scep","SCEP",[174,500,501],{},"ACME",[174,503,504],{},"EST",[174,506,507],{},[241,508,510],{"href":509},"microsoft-rpc-dcom","RPC/DCOM di Microsoft",[174,512,513],{},"SOAP di Microsoft",[174,515,516],{},"Registrazione manuale sulla pagina web della CA",[174,518,519],{},"Altri protocolli proprietari",[521,522,523,524],"table",{},"\n    ",[525,526,527,523,549,530,570,523,590],"tbody",{},[528,529,530,531,530,534,530,537,530,540,530,543,530,546,523],"tr",{},"\n        ",[532,533],"th",{},[532,535,536],{},"DCOM e RPC proprietari di Microsoft",[532,538,539],{},"WS-Trust Enrollment Extension SOAP Enrollment",[532,541,542],{},"Automatic Certificate Management Environment (ACME)",[532,544,545],{},"Simple Certificate Enrollment Protocol (SCEP)",[532,547,548],{},"Enrollment over Secure Transport (EST)",[528,550,530,551,530,555,530,558,530,561,530,564,530,567,523],{},[552,553,554],"td",{},"Specifiche",[552,556,557],{},"Microsoft OpenSpec1",[552,559,560],{},"Microsoft OpenSpec2",[552,562,563],{},"RFC 8555",[552,565,566],{},"Informale, ora RFC 8894",[552,568,569],{},"RFC 7030 (+ …)",[528,571,530,572,530,575,530,578,530,581,530,584,530,587,523],{},[552,573,574],{},"Implementazione",[552,576,577],{},"Lato server: Active Directory CS Lato client: Windows",[552,579,580],{},"Lato server: ADCS, altri?  Lato client: Windows",[552,582,583],{},"Lato server: Let’s Encrypt Lato client: molti",[552,585,586],{},"Molte implementazioni server e client",[552,588,589],{},"Scarsa diffusione",[528,591,530,592,530,595,530,598,530,601,530,604,530,607,523],{},[552,593,594],{},"Autenticazione",[552,596,597],{},"Autenticazione AD",[552,599,600],{},"Autenticazione AD\\* (formalmente, nome utente e password potrebbero non trovarsi in AD)",[552,602,603],{},"Autenticazione DNS",[552,605,606],{},"“SCEP Challenge”",[552,608,609],{},"CBA oppure autenticazione HTTP Basic/Digest",[147,611,498],{"id":497},[164,613,615],{"id":614},"storia-e-specifica","Storia e specifica",[152,617,618,619,625],{},"Il Simple Certificate Enrollment Protocol (SCEP) è stato ideato da Cisco. Benché all'epoca non esistesse alcuno standard, si è diffuso ampiamente nei sistemi MDM. Cisco è poi andata oltre e ha progettato un protocollo successore, Enrollment over Secure Transport (EST), destinato a sostituire SCEP. EST è quindi diventato uno standard pubblico con la RFC 7030 molto prima di SCEP, standardizzato solo in seguito nella ",[241,620,624],{"href":621,"rel":622},"https://www.rfc-editor.org/rfc/rfc8894.html",[623],"nofollow","RFC 8894",", quando era già lo standard di fatto per la registrazione dei certificati nei sistemi MDM.",[164,627,629],{"id":628},"tecnologia","Tecnologia",[152,631,632,633,637,638,642,643,647],{},"SCEP si basa su HTTP. Una SCEP Request è un ",[241,634,636],{"href":635},"important-data-formats#pkcs7","PKCS#7"," cifrato e firmato, inviato al servizio SCEP tramite una richiesta GET o POST. Il servizio risponde con una SCEP Response, anch'essa un PKCS#7 cifrato e firmato. La richiesta contiene una richiesta di firma del certificato in formato ",[241,639,641],{"href":640},"important-data-formats#pkcs10","PKCS#10",", la risposta contiene il ",[241,644,646],{"href":645},"important-data-formats#x509","certificato X.509"," emesso.",[164,649,594],{"id":650},"autenticazione",[152,652,653],{},"La richiesta PKCS#10 contiene una \"SCEP Challenge\" che autentica e autorizza la richiesta di firma tramite un metodo fuori banda, variabile a seconda dello specifico servizio SCEP. Oggi nella pratica si utilizzano tre tipi di SCEP Challenge:",[409,655,657],{"id":656},"scep-challenge-statica","SCEP Challenge statica",[152,659,660],{},"La possibilità più semplice è una passphrase statica. Se la SCEP Challenge contenuta nel PKCS#10 corrisponde a un valore predefinito memorizzato sul servizio SCEP, il certificato viene emesso, altrimenti la richiesta viene rifiutata. Il problema di questo metodo è che non è quasi possibile alcun controllo sulla corrispondenza tra le proprietà richieste per il certificato e il richiedente. Per questo problema esiste persino un CVE.",[152,662,663],{},"Questi metodi si possono distinguere ulteriormente:",[257,665,666,674,681],{},[174,667,668,669,673],{},"Nel caso di una registrazione SCEP ",[670,671,672],"em",{},"diretta",", l'entità per cui va registrato il certificato comunica direttamente con il servizio SCEP. Ad esempio, un sistema MDM indica a uno smartphone Android di effettuare una registrazione SCEP utilizzando la SCEP Challenge \"SecurePassword\". Lo smartphone Android genera una CSR, auspicabilmente con i valori corretti, e vi aggiunge \"SecurePassword\" come SCEP Challenge. Invia quindi la CSR al servizio SCEP e riceve in cambio il certificato emesso.",[174,675,676,677,680],{},"Un ",[670,678,679],{},"SCEP Proxy trasparente"," funziona esattamente come un reverse proxy HTTP. Poiché SCEP è cifrato e firmato, non può realmente esaminare le richieste o le risposte SCEP, né modificarle, ma può controllare chi può registrare certificati e quando, in base ai perimetri di rete.",[174,682,676,683,686],{},[670,684,685],{},"SCEP Proxy adattatore di protocollo"," è un sistema che richiede certificati tramite SCEP per conto di un altro sistema. Ad esempio, un sistema MDM come JAMF potrebbe richiedere un certificato a un servizio SCEP per conto di un iPhone. Una volta ottenuti il certificato e la chiave privata, può distribuire il certificato tramite un altro protocollo. In questo modo solo il sistema MDM ha accesso alla SCEP Challenge e può anche controllare il contenuto del certificato.",[409,688,690],{"id":689},"scep-challenge-dinamica","SCEP Challenge dinamica",[152,692,693],{},"In questo caso ogni SCEP Challenge è valida per una sola richiesta di certificato. Questo consente al servizio SCEP di identificare la richiesta SCEP e di verificare che le proprietà richieste per il certificato corrispondano a quelle consentite per quella specifica richiesta.",[152,695,696],{},"Nella pratica si utilizzano in genere due modalità con cui un sistema MDM e una CA SCEP possono concordare la SCEP Challenge da usare per una richiesta:",[257,698,699,707],{},[174,700,701,702],{},"Il sistema MDM, quando ne ha bisogno, richiede al servizio SCEP un codice monouso per una SCEP Request.\n",[257,703,704],{},[174,705,706],{},"Un esempio è Microsoft NDES. NDES dispone di una pagina \"admin\" separata, autenticata con le credenziali AD. A ogni accesso alla pagina di amministrazione viene creato e mostrato un nuovo codice monouso, utilizzabile per una singola richiesta SCEP. In questa configurazione, però, NDES non verifica alcuna proprietà del certificato, perché il codice monouso è generico.",[174,708,709],{},"Il sistema MDM genera un codice monouso quando comunica a un sistema gestito di richiedere un certificato tramite SCEP. Quando la SCEP Request arriva al servizio SCEP, il servizio deve recuperare il codice monouso dal sistema MDM, di solito con un web hook, e verificare che corrisponda alla SCEP Challenge presente nella richiesta. Per questo protocollo non esiste uno standard, quindi il sistema MDM e il servizio SCEP devono concordare un formato, e dipende dall'implementazione se le proprietà della richiesta vengono verificate.",[409,711,713],{"id":712},"metadati-firmati","Metadati firmati",[152,715,716],{},"Per la SCEP Challenge non esiste praticamente alcun limite di lunghezza. Non deve quindi essere per forza una \"passphrase\" comprensibile per una persona, ma può anche essere un BLOB.",[152,718,719],{},"Intune utilizza come SCEP Challenge un XML firmato e cifrato. Lo crea sul lato server e lo invia a un dispositivo client quando vuole registrare un certificato e genera la SCEP Request.",[152,721,722],{},"Il servizio SCEP deve inviare l'intera richiesta PKCS#10 a un servizio Intune SCEP Challenge. Il servizio SCEP Challenge dispone della chiave privata per decifrare l'XML e della chiave pubblica per verificare che sia stato creato da un servizio Intune autentico.",[152,724,725],{},"L'XML contiene metadati sulla richiesta, ad esempio come deve essere composto il Subject. Questi derivano da un lato dal profilo di configurazione SCEP, dall'altro dai dati specifici dell'oggetto utente o dispositivo per cui il certificato deve essere emesso.",[152,727,728],{},"Ad esempio, il profilo di configurazione SCEP potrebbe impostare CN={{DeviceId}} come subject. Quando il dispositivo con id xyz richiede un certificato, l'XML indica che il subject deve essere CN=xyz. Il servizio SCEP Challenge confronta quindi le informazioni dell'XML con il subject presente nella richiesta PKCS#10. La convalida fallisce se i subject differiscono e riesce se questa e le altre proprietà corrispondono.",[152,730,731],{},"Il servizio SCEP emette il certificato solo se la convalida riesce.",[152,733,734,735,740],{},"Microsoft offre ",[241,736,739],{"href":737,"rel":738},"https://learn.microsoft.com/en-us/mem/intune/protect/certificate-authority-add-scep-overview#overview",[623],"un articolo"," che spiega questa verifica.",[152,742,743],{},"Microsoft NDES lo supporta con un modulo di policy NDES aggiuntivo, mentre altre CA SCEP possono supportarlo nativamente oppure no.",[147,745,747],{"id":746},"microsoft-rpcdcom","Microsoft RPC/DCOM",[164,749,751],{"id":750},"storia","Storia",[152,753,754],{},"Microsoft Active Directory Certificate Services (ADCS), a volte chiamato semplicemente \"CA Microsoft\", è il software di autorità di certificazione integrato in Windows Server. Il software è stato sviluppato in origine alla fine del millennio scorso e ha continuato a ricevere alcune aggiunte nei dieci o quindici anni successivi.",[152,756,757,758,760],{},"Un'alternativa è il protocollo SOAP di Microsoft oppure ",[241,759,498],{"href":497},", che Microsoft chiama rispettivamente Web Enrollment e NDES.",[164,762,764],{"id":763},"specifica-e-diffusione","Specifica e diffusione",[152,766,767,768,773],{},"Non risulta che altri sistemi CA implementino questo protocollo, anche se nel frattempo Microsoft ne ha pubblicato ",[241,769,772],{"href":770,"rel":771},"https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cersod/dd034cb3-99fc-4c10-92c8-1fbeb4788183",[623],"la specifica in Microsoft OpenSpec",". Sul lato client, Windows supporta il protocollo in modo nativo, mentre le altre piattaforme non sono supportate.",[164,775,629],{"id":776},"tecnologia-1",[152,778,779],{},"Il suo metodo di registrazione principale è un protocollo proprietario basato su RPC o DCOM.",[152,781,782],{},"Anche l'autoenrollment utilizza questo protocollo. Perché l'autoenrollment funzioni servono",[171,784,785,788,791,794,797],{},[174,786,787],{},"un dispositivo aggiunto al dominio.",[174,789,790],{},"Un criterio di gruppo che abiliti l'autoenrollment,",[174,792,793],{},"una CA Enterprise (e non stand-alone)",[174,795,796],{},"che registri un modello di certificato per il quale",[174,798,799],{},"l'utente o il dispositivo dispone delle autorizzazioni di enrollment e autoenrollment.",[152,801,802,803,807,808,811],{},"L'intervallo predefinito per il controllo degli autoenrollment è di 8 ore, anche se lo si può forzare con ",[804,805,806],"code",{},"certutil -pulse"," o, spesso meglio, con ",[804,809,810],{},"gpupdate -force",".",[164,813,594],{"id":814},"autenticazione-1",[152,816,817],{},"Questo protocollo utilizza i protocolli di autenticazione integrati in Active Directory, ossia utenti e computer si autenticano con le proprie credenziali AD.",[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":434,"searchDepth":435,"depth":435,"links":823},[824,829],{"id":497,"depth":435,"text":498,"children":825},[826,827,828],{"id":614,"depth":440,"text":615},{"id":628,"depth":440,"text":629},{"id":650,"depth":440,"text":594},{"id":746,"depth":435,"text":747,"children":830},[831,832,833,834],{"id":750,"depth":440,"text":751},{"id":763,"depth":440,"text":764},{"id":776,"depth":440,"text":629},{"id":814,"depth":440,"text":594},{"lang":461,"seoTitle":836,"titleClass":462,"socialimg":837,"blogtitlepic":838,"customExcerpt":839,"keywords":840,"asideNav":841,"maxContent":472},"Metodi di registrazione dei certificati - SCEP, ACME, EST e Microsoft RPC","/blog/heads/header-scepman-enrollment-methods.png","header-scepman-enrollment-methods.png","Come funziona la registrazione dei certificati con SCEP, ACME, EST, Microsoft RPC e i metodi manuali. Un confronto tra i protocolli di registrazione di una PKI per l'emissione sicura dei certificati.","metodi di registrazione dei certificati, SCEP, ACME, EST, Microsoft RPC, protocollo di registrazione dei certificati, registrazione dei certificati nella PKI, enrollment over secure transport, Simple Certificate Enrollment Protocol, Automatic Certificate Management Environment, registrazione dei certificati Microsoft",{"menuItems":842},[843,845],{"href":844,"text":498},"#scep",{"href":846,"text":747},"#microsoft-rpcdcom","/glossary/enrollment-methods",{"title":479,"description":484},"glossary/enrollment-methods","S-bowxBLaMO2WQs6pJBg8x8k4PBsKFBAR2x66tIT1uQ",{"id":852,"title":853,"author":142,"body":854,"cta":142,"description":434,"eventid":142,"extension":457,"hideInRecent":458,"layout":459,"meta":1088,"moment":142,"navigation":472,"path":1106,"seo":1107,"stem":1108,"tags":142,"webcast":458,"__hash__":1109},"content_it/glossary/important-data-formats.md","Formati di dati importanti",{"type":144,"value":855,"toc":1071},[856,860,879,886,889,893,897,900,903,906,910,913,917,920,923,931,934,938,945,948,951,954,965,969,982,986,989,992,995,998,1006,1010,1013,1016,1019,1030,1034,1037,1041,1050,1054,1062,1065],[147,857,859],{"id":858},"x509","X.509",[152,861,862,863,866,867,872,873,878],{},"X.509 è ",[670,864,865],{},"lo"," standard per i certificati digitali. In passato esistevano alcuni concorrenti come ",[241,868,871],{"href":869,"rel":870},"https://www.rfc-editor.org/rfc/rfc4880",[623],"OpenPGP",", ma oggi sono molto meno utilizzati. Un momento però ... X.509 non è in realtà lo standard giusto. X.509 è propriamente uno standard ITU-T, mentre le definizioni che contano davvero fanno parte della ",[241,874,877],{"href":875,"rel":876},"https://www.rfc-editor.org/rfc/rfc5280",[623],"RFC 5280",", ossia di uno standard IETF e non ITU-T. La RFC definisce, sulla base di X.509, il \"PKI Profile for the Internet\", ed è l'unico profilo che nella pratica conti davvero.",[152,880,881,882,885],{},"Un certificato digitale si basa sulla crittografia asimmetrica e in particolare sulle firme digitali. Il caso d'uso più comune per un certificato digitale è oggi l'autenticazione dei server. Tutti li hanno già utilizzati, probabilmente senza sapere che si trattava di un certificato X.509: ogni volta che si accede a un sito web HTTP",[156,883,884],{},"S",", il browser stabilisce una connessione TLS con il server web. Il server web utilizza un certificato X.509 per dimostrare la propria identità. Ad esempio, quando si accede al sito della propria banca per disporre un bonifico, si vuole essere certi di comunicare davvero con la propria banca. Gli attaccanti potrebbero provare a impersonare il sito della banca, leggere la password e il TAN dell'utente e poi trasferire il denaro su un conto che controllano. HTTPS aiuta a impedirlo, perché gli attaccanti non dispongono del certificato X.509 del server web della banca. Quando il browser indica che si sta accedendo a un determinato dominio tramite una connessione HTTPS, il certificato garantisce che la connessione avvenga davvero con un server web di chi possiede quel dominio.",[152,887,888],{},"Come fa il certificato a ottenere questo risultato? Il certificato contiene alcuni metadati, la chiave pubblica di una coppia di chiavi crittografiche e una firma di un'autorità di certificazione. Vediamo le tre parti una per una:",[164,890,892],{"id":891},"contenuto-di-un-certificato-x509","Contenuto di un certificato X.509",[409,894,896],{"id":895},"metadati","Metadati",[152,898,899],{},"I metadati del certificato X.509 indicano, tra le altre cose, per quale periodo il certificato è valido, per quale scopo deve essere utilizzato e a chi è stato emesso. In particolare, per un certificato TLS di server, contengono il dominio del server web. Il browser confronta il dominio a cui ha tentato di accedere con quello presente nel certificato. Se non coincidono, il browser non prosegue e mostra un avviso. Se il certificato è scaduto, mostra ugualmente un avviso.",[152,901,902],{},"Curiosamente, i browser spesso non mostravano alcun avviso quando si accedeva a un sito HTTP senza TLS, benché questo sia ancora meno sicuro. Accedendo a un server web con un certificato X.509 non valido può trattarsi semplicemente di una configurazione errata, e la connessione potrebbe comunque essere al riparo da attaccanti che la spiano, mentre una connessione HTTP non offre alcuna protezione.",[152,904,905],{},"Su questo fronte ci sono comunque dei progressi, ad esempio il certificate pinning. Si tratta però di un argomento avanzato, quindi conviene passare agli altri due elementi presenti in un certificato X.509.",[409,907,909],{"id":908},"chiave-pubblica","Chiave pubblica",[152,911,912],{},"Il certificato contiene la parte pubblica di una coppia di chiavi asimmetrica. La crittografia consente al server web, o più in generale al titolare del certificato in altri casi d'uso, di dimostrare di possedere anche la parte privata della coppia di chiavi senza esporla al client che si connette né ad altri. Il client può quindi essere certo che il server web sia davvero il proprietario del certificato e non qualcuno che lo ha semplicemente copiato. Copiare il certificato in sé è in effetti piuttosto semplice, dato che il server web ne invia una copia a chiunque tenti di connettersi. Sottrarre la chiave privata è invece difficile o impossibile, perché non lascia mai il server web. Esistono diversi metodi per rendere ancora più difficile la sottrazione della chiave privata, ad esempio HSM e TPM.",[409,914,916],{"id":915},"firma-di-unautorità-di-certificazione","Firma di un'autorità di certificazione",[152,918,919],{},"I metadati consentono al client di verificare che il certificato sia adatto allo specifico caso d'uso. La chiave pubblica dimostra che la controparte è davvero il proprietario del certificato. Ma un attaccante potrebbe semplicemente creare una nuova coppia di chiavi e un nuovo certificato che soddisfano anch'essi questi due criteri. Come può allora un client sapere che il certificato è affidabile?",[152,921,922],{},"Il certificato contiene una firma crittografica prodotta con un'altra coppia di chiavi, appartenente al certificato di un'autorità di certificazione (CA). Il certificato della CA può essere verificato allo stesso modo ed è a sua volta firmato da un certificato. Il client può seguire questa \"catena di fiducia\" dal cosiddetto certificato foglia fino al certificato della Root CA, che riconosce dal fatto di essere autofirmato, ossia la firma del certificato proviene dalla sua stessa coppia di chiavi. Di norma si tratta di uno o due passaggi soltanto, quindi sono coinvolti solo uno o due certificati CA.",[152,924,925,926,930],{},"Le CA devono verificare con attenzione che i metadati siano corretti quando ",[241,927,929],{"href":928},"enrollment-methods/","emettono un certificato",". Ad esempio, per ottenere un certificato TLS di server per il proprio dominio occorre dimostrare alla CA di esserne davvero il titolare. A seconda del grado di accuratezza di questa verifica si ottiene un certificato di base oppure un certificato Extended Validation (EV).",[152,932,933],{},"Ogni browser e ogni sistema operativo include un elenco predefinito di Root CA attendibili. Utenti e amministratori possono aggiungere altre Root CA attendibili. Alcune Root CA sono considerate attendibili solo per scopi specifici, altre godono di una fiducia più generale. Il client verifica se la catena di fiducia termina in una Root CA attendibile. In tal caso, e se tutti i certificati della catena sono ancora validi e i metadati indicano che vengono utilizzati secondo la loro finalità, il certificato foglia del server web è considerato attendibile e la connessione viene stabilita.",[164,935,937],{"id":936},"validità-dei-certificati-x509","Validità dei certificati X.509",[152,939,940,941,811],{},"Nei certificati X.509 tutto ruota attorno alla fiducia, che va prima costruita. Come spiegato, un criterio di questa fiducia è che il certificato risalga fino a una Root CA attendibile. Un altro è che si trovi all'interno del proprio periodo di validità. Di solito questo significa che non è scaduto, ma, in genere a causa di errori tecnici, un certificato può anche non essere ancora valido. C'è però un ulteriore criterio: la CA che ha emesso il certificato non deve averlo revocato. Poiché si tratta di un argomento a sé, gli abbiamo dedicato un ",[241,942,944],{"href":943},"other-stuff/certificate-lifecycle-management","articolo separato",[147,946,636],{"id":947},"pkcs7",[152,949,950],{},"PKCS#7 è il coltellino svizzero dei formati di dati crittografici e può contenere praticamente qualsiasi cosa: messaggi cifrati, messaggi firmati, messaggi firmati e cifrati, certificati e chiavi private",[152,952,953],{},"Questo è anche il principale svantaggio del formato. Quando un'applicazione o un utente riceve un PKCS#7, non è di per sé chiaro che cosa farne. Ecco alcuni casi d'uso importanti:",[171,955,956,959,962],{},[174,957,958],{},"I messaggi S/MIME sono in sostanza email con corpo o allegati in formato PKCS#7.",[174,960,961],{},"Le richieste e le risposte SCEP sono entrambe, di fatto, messaggi firmati PKCS#7.",[174,963,964],{},"Le risposte EST sono messaggi CMS.",[164,966,968],{"id":967},"codifica","Codifica",[152,970,971,972,976,977,981],{},"Le estensioni di file più comuni sono .p7b (",[241,973,975],{"href":974},"asn.1-and-pem#der-encoding","codifica DER","), .p7s (un messaggio firmato o la firma di un messaggio) e .p7m (un messaggio firmato e/o cifrato). È definita anche la ",[241,978,980],{"href":979},"asn.1-and-pem#pem-encoding","codifica PEM"," con etichetta \"PKCS7\", ma viene usata raramente.",[164,983,985],{"id":984},"strumenti","Strumenti",[152,987,988],{},"In Windows è possibile aprire i messaggi PKCS#7 con un doppio clic e le estensioni Crypto-shell li visualizzano. Di norma, però, se ne possono estrarre solo i certificati e le relative chiavi private, non il contenuto dei messaggi.",[152,990,991],{},"Questi file si possono convertire in altri formati con strumenti come OpenSSL.",[147,993,641],{"id":994},"pkcs10",[152,996,997],{},"Una richiesta di firma del certificato (CSR) come definita in PKCS#10 è un file che contiene la descrizione di un certificato che si desidera ottenere da un'autorità di certificazione (CA). Ha una struttura simile a quella di un certificato X.509, ma manca della firma di una CA. Contiene invece la firma di chi richiede il certificato. Resta comunque un formato diverso, quindi non equivale a un certificato autofirmato.",[152,999,1000,1001,811],{},"Può essere in formato binario con codifica DER oppure con codifica PEM ",[241,1002,1005],{"href":1003,"rel":1004},"https://datatracker.ietf.org/doc/html/rfc7468#section-7",[623],"utilizzando l'etichetta \"CERTIFICATE REQUEST\"",[147,1007,1009],{"id":1008},"pkcs12","PKCS#12",[152,1011,1012],{},"PKCS#12 è noto anche come PFX, soprattutto negli ambienti Windows. Le estensioni di file più comuni sono quindi .pfx e .p12. Contiene certificati X.509 e quasi sempre le corrispondenti chiavi private, anche se tecnicamente questo non è imposto.",[152,1014,1015],{},"I dati di un file PKCS#12 sono di solito cifrati con password. Spesso è cifrata solo la chiave privata, quindi si potrebbero estrarre i certificati senza conoscere le password, se l'applicazione lo consente (la maggior parte non lo permette). PKCS#12 è il modo più comune negli ambienti Windows per conservare un certificato e la relativa chiave privata in un file. Negli ambienti Linux sono invece più diffusi i file PKCS#8 con codifica PEM.",[152,1017,1018],{},"Poiché lo standard offre molte opzioni su come conservare certificati e chiavi private in \"safebag\" annidati, i file PKCS#12 presentano alcuni problemi di compatibilità, ad esempio:",[171,1020,1021,1024,1027],{},[174,1022,1023],{},"Windows è noto per associare le chiavi private di un PKCS#12 a tutti i certificati estratti dal file, non solo a quello a cui sono destinate. Se il PKCS#12 contiene una catena di certificati, Windows potrebbe indicare di possedere la chiave privata del certificato CA.",[174,1025,1026],{},"Su macOS non è possibile importare file PKCS#12 se gli algoritmi crittografici sono troppo recenti.",[174,1028,1029],{},"Può essere necessario cifrare i certificati contenuti in un file PKCS#12 affinché le applicazioni riceventi possano estrarli. Alcune però supportano solo algoritmi molto vecchi e deboli, il che di norma non è un problema, dato che si tratta comunque di informazioni pubbliche. OpenSSL 3.x, tuttavia, non supporta questi algoritmi obsoleti e vulnerabili e si rifiuta di aprire il PKCS#12.",[147,1031,1033],{"id":1032},"asn1-e-pem","ASN.1 e PEM",[152,1035,1036],{},"L'Abstract Syntax Notation One (ASN.1) è un linguaggio utilizzato per descrivere strutture di dati. Esistono alcuni tipi di dati di base predefiniti, come gli interi o le sequenze, e chi redige un protocollo o un formato di file può poi definire tipi di dati personalizzati a partire da quelli di base.",[164,1038,1040],{"id":1039},"codifica-der","Codifica DER",[152,1042,1043,1044,1049],{},"Lo ",[241,1045,1048],{"href":1046,"rel":1047},"https://www.itu.int/rec/T-REC-X.680/",[623],"standard ITU-T X.680"," definisce diverse codifiche per i dati specificati in ASN.1. Per i dati legati a X.509 la codifica più importante è DER, perché esiste un solo modo di codificare un tipo: un hash della rappresentazione binaria DER del tipo avrà quindi sempre lo stesso valore, il che è importante ad esempio quando si firmano dati codificati in ASN.1.",[164,1051,1053],{"id":1052},"codifica-pem","Codifica PEM",[152,1055,1056,1057,1061],{},"Per molti, ma non per tutti i tipi di file legati a X.509, si può conservare il file in forma binaria con codifica DER oppure applicare una ",[241,1058,980],{"href":1059,"rel":1060},"https://datatracker.ietf.org/doc/html/rfc7468",[623]," aggiuntiva sopra la codifica DER. PEM utilizza solo caratteri ASCII e può quindi essere copiato e incollato facilmente negli appunti o, qualche decennio fa quando la cosa era ancora rilevante, inviato per email.",[164,1063,985],{"id":1064},"strumenti-1",[152,1066,1067,1068,811],{},"Se si dispone di un file codificato in ASN.1 e non se ne conosce il tipo, oppure non si ha un'applicazione in grado di gestire quel tipo specifico, è comunque possibile decodificare la struttura ASN.1 grezza e vedere che cosa contiene. In Windows lo strumento integrato certutil può farlo con il comando ",[804,1069,1070],{},"certutil -decode",{"title":434,"searchDepth":435,"depth":435,"links":1072},[1073,1077,1081,1082,1083],{"id":858,"depth":435,"text":859,"children":1074},[1075,1076],{"id":891,"depth":440,"text":892},{"id":936,"depth":440,"text":937},{"id":947,"depth":435,"text":636,"children":1078},[1079,1080],{"id":967,"depth":440,"text":968},{"id":984,"depth":440,"text":985},{"id":994,"depth":435,"text":641},{"id":1008,"depth":435,"text":1009},{"id":1032,"depth":435,"text":1033,"children":1084},[1085,1086,1087],{"id":1039,"depth":440,"text":1040},{"id":1052,"depth":440,"text":1053},{"id":1064,"depth":440,"text":985},{"lang":461,"seoTitle":1089,"titleClass":462,"blogtitlepic":1090,"socialimg":1091,"customExcerpt":1092,"keywords":1093,"asideNav":1094,"maxContent":472},"Formati di dati importanti - X.509, PKCS, ASN.1 e PEM spiegati","header-scepman-important-data-formats.png","/blog/heads/header-scepman-important-data-formats.png","Una panoramica dei formati essenziali della crittografia e dei certificati: X.509, PKCS 7, PKCS 10, PKCS 12, ASN.1 e PEM.","formati di dati importanti, certificato X.509, formati PKCS, PKCS 7, PKCS 10, PKCS 12, ASN.1, formato PEM, certificati digitali, public key infrastructure, formati PKI",{"menuItems":1095},[1096,1098,1100,1102,1104],{"href":1097,"text":859},"#x509",{"href":1099,"text":636},"#pkcs7",{"href":1101,"text":641},"#pkcs10",{"href":1103,"text":1009},"#pkcs12",{"href":1105,"text":1033},"#asn1-e-pem","/glossary/important-data-formats",{"title":853,"description":434},"glossary/important-data-formats","NFewHqBQapjk-aEV-geCBVEEu_pEIj4FdahlYaN7qmA",{"id":1111,"title":1112,"author":142,"body":1113,"cta":142,"description":434,"eventid":142,"extension":457,"hideInRecent":458,"layout":459,"meta":1336,"moment":142,"navigation":472,"path":1342,"seo":1343,"stem":1344,"tags":142,"webcast":458,"__hash__":1345},"content_it/glossary/public-key-infrastructure.md","Public Key Infrastructure",{"type":144,"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],[147,1116,1118],{"id":1117},"stabilire-la-fiducia","Stabilire la fiducia",[164,1120,1122,1123,1126],{"id":1121},"come-indica-un-client-la-propria-fiducia-in-una-determinata-root-ca","Come ",[156,1124,1125],{},"indica"," un client la propria fiducia in una determinata Root CA?",[152,1128,1129],{},"Un client manifesta la propria fiducia in una determinata autorità di certificazione (CA) radice attraverso un processo che si basa sulla catena di fiducia dei certificati. Ecco come funziona:",[171,1131,1132,1138,1144,1150,1156],{},[174,1133,1134,1137],{},[156,1135,1136],{},"Certificati radice preinstallati:"," la maggior parte dei sistemi operativi e dei browser web include una serie di certificati radice preinstallati, provenienti da CA attendibili. Questi certificati radice sono conservati in un archivio radice attendibile.",[174,1139,1140,1143],{},[156,1141,1142],{},"Convalida del certificato:"," quando un client si connette a un server, ad esempio visitando un sito web, il server presenta il proprio certificato TLS. Di norma questo certificato è firmato da una CA intermedia, a sua volta firmata da una Root CA.",[174,1145,1146,1149],{},[156,1147,1148],{},"Verifica della catena di fiducia:"," il client verifica la catena di fiducia controllando se il certificato presentato è firmato da una Root CA attendibile. Verifica inoltre se le CA intermedie della catena sono attendibili.",[174,1151,1152,1155],{},[156,1153,1154],{},"Firme digitali:"," ogni certificato della catena è firmato digitalmente dalla CA che lo precede. Il client utilizza la chiave pubblica della CA per verificare queste firme, accertando che i certificati non siano stati manomessi.",[174,1157,1158,1161],{},[156,1159,1160],{},"Decisione di fiducia:"," se l'intera catena di fiducia è valida e risale a una Root CA attendibile, il client considera attendibile il certificato del server. La comunicazione sicura può quindi proseguire.",[164,1163,1165],{"id":1164},"qual-è-il-vantaggio-delle-ca-intermedie-rispetto-a-una-sola-root-ca","Qual è il vantaggio delle CA intermedie rispetto a una sola Root CA?",[152,1167,1168],{},"Per le PKI di infrastruttura, una sola CA radice può in realtà risultare vantaggiosa.",[164,1170,1172],{"id":1171},"come-ottiene-il-proprio-certificato-una-ca-intermedia","Come ottiene il proprio certificato una CA intermedia?",[152,1174,1175],{},"Un'autorità di certificazione (CA) intermedia ottiene il proprio certificato attraverso un processo chiamato cross-signing da parte di una Root CA. Ecco come funziona:",[257,1177,1178,1184,1190,1195,1200],{},[174,1179,1180,1183],{},[156,1181,1182],{},"Richiesta di firma del certificato (CSR):"," l'organizzazione che intende allestire una CA intermedia genera una CSR. Questa CSR include la chiave pubblica e le informazioni identificative della CA intermedia.",[174,1185,1186,1189],{},[156,1187,1188],{},"Invio alla Root CA:"," la CSR viene inviata a una Root CA attendibile.",[174,1191,1192,1194],{},[156,1193,361],{}," la Root CA verifica l'identità e la legittimità dell'organizzazione che richiede il certificato intermedio.",[174,1196,1197,1199],{},[156,1198,349],{}," una volta completata la verifica, la Root CA utilizza la propria chiave privata per firmare la CSR e creare il certificato intermedio. Questo certificato firmato collega la CA intermedia alla Root CA, stabilendo una catena di fiducia.",[174,1201,1202,1205],{},[156,1203,1204],{},"Emissione:"," la Root CA emette il certificato intermedio firmato a favore dell'organizzazione richiedente, che può quindi utilizzarlo per firmare certificati di entità finale, ad esempio certificati TLS per siti web.",[152,1207,1208],{},"Questo processo garantisce che la CA intermedia sia considerata attendibile in virtù del suo collegamento con la Root CA, già ritenuta attendibile da browser e sistemi operativi.",[164,1210,1212],{"id":1211},"che-cosè-una-catena-di-certificati-come-funziona","Che cos'è una catena di certificati? Come funziona?",[152,1214,1215],{},"Una catena di certificati, nota anche come catena di fiducia, è una sequenza di certificati che garantisce l'autenticità e l'affidabilità di un certificato digitale. Ecco come funziona:",[171,1217,1218,1224,1230],{},[174,1219,1220,1223],{},[156,1221,1222],{},"Processo di verifica:"," quando un client, ad esempio un browser web, si connette a un server, il server presenta il proprio certificato di entità finale. Il client verifica quindi la catena di certificati per accertare che ogni certificato sia firmato dal certificato successivo della catena, fino al certificato radice.",[174,1225,1226,1229],{},[156,1227,1228],{},"Catena di fiducia:"," ogni certificato della catena viene verificato utilizzando la chiave pubblica del certificato che lo precede. Il procedimento continua fino al certificato radice, già considerato attendibile dal client.",[174,1231,1232,1235],{},[156,1233,1234],{},"Costruzione della fiducia:"," se l'intera catena è valida e risale a un certificato radice attendibile, il client considera attendibile il certificato di entità finale e la comunicazione sicura può proseguire.",[152,1237,1238],{},"Questo sistema garantisce che il certificato di entità finale sia legittimo e sia stato emesso da un'autorità attendibile, preservando l'integrità e la sicurezza delle comunicazioni digitali.",[164,1240,1242],{"id":1241},"quale-problema-cerca-di-risolvere-lestensione-basic-constraints","Quale problema cerca di risolvere l'estensione Basic Constraints?",[152,1244,1245,1246,1249],{},"L'estensione ",[156,1247,1248],{},"Basic Constraints"," di un certificato digitale affronta il problema di distinguere i diversi tipi di certificati e i loro ruoli all'interno di una Public Key Infrastructure (PKI). Ecco come funziona:",[171,1251,1252,1258],{},[174,1253,1254,1257],{},[156,1255,1256],{},"Identificazione dell'autorità di certificazione (CA):"," indica se un certificato è un certificato CA oppure un certificato di entità finale. Questa distinzione è fondamentale, perché i certificati CA possono emettere altri certificati, mentre i certificati di entità finale non possono farlo.",[174,1259,1260,1263],{},[156,1261,1262],{},"Vincolo sulla lunghezza del percorso:"," può limitare il numero di CA intermedie che possono esistere al di sotto di questa CA nella catena di certificati. Questo aiuta a evitare catene di certificati eccessivamente lunghe, che possono risultare inefficienti e potenzialmente insicure.",[152,1265,1266],{},[156,1267,1268],{},"Problemi risolti:",[171,1270,1271,1277],{},[174,1272,1273,1276],{},[156,1274,1275],{},"Prevenzione dell'emissione non autorizzata di certificati:"," indicando chiaramente quali certificati possono agire da CA, impedisce che i certificati di entità finale emettano altri certificati, preservando così l'integrità della PKI.",[174,1278,1279,1282],{},[156,1280,1281],{},"Gestione della lunghezza della catena di certificati:"," limitare la lunghezza del percorso assicura che la catena di certificati resti gestibile e sicura, prevenendo le potenziali vulnerabilità legate alle catene lunghe",[164,1284,1286],{"id":1285},"quali-meccanismi-utilizza-per-risolvere-questi-problemi"," Quali meccanismi utilizza per risolvere questi problemi?",[152,1288,1245,1289,1291],{},[156,1290,1248],{}," di un certificato digitale utilizza i meccanismi seguenti per risolvere i problemi legati alla distinzione tra certificati CA e certificati di entità finale e alla gestione della lunghezza della catena di certificati:",[171,1293,1294,1300],{},[174,1295,1296,1299],{},[156,1297,1298],{},"Flag CA:"," questo flag indica se il certificato è un certificato di autorità di certificazione (CA) oppure un certificato di entità finale. Se il flag è impostato su TRUE, il certificato può essere utilizzato per firmare altri certificati, ossia è un certificato CA. Se è impostato su FALSE, si tratta di un certificato di entità finale e non può emettere altri certificati.",[174,1301,1302,1304],{},[156,1303,1262],{}," specifica il numero massimo di certificati intermedi non auto-emessi che possono seguire questo certificato in un percorso di certificazione valido. Impostando questo vincolo, l'estensione limita la lunghezza della catena di certificati, mantenendola gestibile e sicura.",[152,1306,1307],{},[156,1308,1309],{},"Come funzionano questi meccanismi:",[171,1311,1312,1317],{},[174,1313,1314,1316],{},[156,1315,1298],{}," quando un certificato viene emesso, il flag CA viene impostato in base all'uso previsto del certificato. Durante il processo di convalida del certificato, i client controllano questo flag per stabilire se il certificato può essere ritenuto affidabile per emettere altri certificati.",[174,1318,1319,1321],{},[156,1320,1262],{}," questo valore viene controllato durante il processo di convalida per accertare che la catena di certificati non superi la lunghezza indicata. Se la catena è troppo lunga, il certificato è considerato non valido.",[152,1323,1324],{},"Questi meccanismi contribuiscono a preservare l'integrità e la sicurezza della Public Key Infrastructure (PKI), assicurando che solo i certificati autorizzati possano emettere altri certificati e impedendo catene di certificati eccessivamente lunghe.",{"title":434,"searchDepth":435,"depth":435,"links":1326},[1327],{"id":1117,"depth":435,"text":1118,"children":1328},[1329,1331,1332,1333,1334,1335],{"id":1121,"depth":440,"text":1330},"Come indica un client la propria fiducia in una determinata Root CA?",{"id":1164,"depth":440,"text":1165},{"id":1171,"depth":440,"text":1172},{"id":1211,"depth":440,"text":1212},{"id":1241,"depth":440,"text":1242},{"id":1285,"depth":440,"text":1286},{"lang":461,"seoTitle":1337,"titleClass":462,"socialimg":1338,"blogtitlepic":1339,"customExcerpt":1340,"keywords":1341,"maxContent":472},"Stabilire la fiducia in una public key infrastructure: il modello di fiducia dei certificati PKI","/blog/heads/header-scepman-public-key-infrastructure.png","header-scepman-public-key-infrastructure.png","Costruire la fiducia in una PKI con catene di certificati, Root CA e CA intermedie e una convalida sicura dei certificati.","stabilire la fiducia PKI, fiducia nella public key infrastructure, catena di fiducia dei certificati, fiducia nella Root CA, fiducia nella CA intermedia, modello di fiducia PKI, convalida dei certificati, certificati radice attendibili, verifica sicura dei certificati, verifica della catena di fiducia","/glossary/public-key-infrastructure",{"title":1112,"description":434},"glossary/public-key-infrastructure","m6KkXMjvPiNcznRI6oeKiBkzt3GekGt1e5BPPefemXA",{"id":1347,"title":1348,"author":142,"body":1349,"cta":142,"description":434,"eventid":142,"extension":457,"hideInRecent":458,"layout":459,"meta":1789,"moment":142,"navigation":472,"path":1795,"seo":1796,"stem":1797,"tags":142,"webcast":458,"__hash__":1798},"content_it/glossary/use-cases-for-certificates.md","Casi d'uso dei certificati",{"type":144,"value":1350,"toc":1774},[1351,1355,1359,1373,1377,1409,1413,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,1665,1685,1690,1707,1712,1732,1736,1739,1771],[147,1352,1354],{"id":1353},"transport-layer-security-tls","Transport Layer Security (TLS)",[164,1356,1358],{"id":1357},"quali-sono-le-due-domande-che-un-client-deve-porsi-quando-riceve-un-certificato-da-un-server","Quali sono le due domande che un client deve porsi quando riceve un certificato da un server?",[257,1360,1361,1367],{},[174,1362,1363,1366],{},[156,1364,1365],{},"Il certificato è valido e attendibile?"," Il client deve verificare che il certificato sia stato emesso da un'autorità di certificazione (CA) attendibile e che non sia scaduto né revocato. Questo comporta il controllo del periodo di validità del certificato e la verifica che sia firmato da una CA di cui il client si fida.",[174,1368,1369,1372],{},[156,1370,1371],{},"Il certificato corrisponde all'identità del server?"," Il client deve accertare che i dati del certificato, come il Common Name (CN) o il Subject Alternative Name (SAN), corrispondano al nome di dominio del server. Questo aiuta a confermare che il certificato sia effettivamente destinato al server a cui il client sta tentando di connettersi.",[164,1374,1376],{"id":1375},"come-verifica-il-client-che-un-certificato-sia-affidabile","Come verifica il client che un certificato sia affidabile?",[257,1378,1379,1385,1391,1397,1403],{},[174,1380,1381,1384],{},[156,1382,1383],{},"Controllo della catena di fiducia del certificato:"," il client verifica la catena di certificati, che comprende il certificato del server, gli eventuali certificati intermedi e il certificato radice. Ogni certificato della catena deve essere firmato dall'autorità immediatamente superiore, fino ad arrivare a un certificato radice attendibile.",[174,1386,1387,1390],{},[156,1388,1389],{},"Verifica del periodo di validità del certificato:"," il client controlla il periodo di validità del certificato per accertare che non sia scaduto e che sia già valido. Questo comporta il controllo delle date \"Not Before\" e \"Not After\" presenti nel certificato.",[174,1392,1393,1396],{},[156,1394,1395],{},"Corrispondenza tra certificato e identità del server:"," il client verifica che il Common Name (CN) o il Subject Alternative Name (SAN) del certificato corrisponda al nome di dominio del server. In questo modo si conferma che il certificato è destinato al server a cui il client si sta connettendo.",[174,1398,1399,1402],{},[156,1400,1401],{},"Controllo della revoca:"," il client verifica se il certificato è stato revocato interrogando la Certificate Revocation List (CRL) oppure utilizzando l'Online Certificate Status Protocol (OCSP). Un certificato revocato non è più attendibile.",[174,1404,1405,1408],{},[156,1406,1407],{},"Verifica della firma digitale:"," il client verifica la firma digitale presente sul certificato per accertare che non sia stato manomesso. Questo comporta il controllo della firma crittografica rispetto alla chiave pubblica della CA emittente.",[164,1410,1412],{"id":1411},"come-verifica-il-client-che-il-server-sia-il-reale-proprietario-di-un-certificato","Come verifica il client che il server sia il reale proprietario di un certificato?",[257,1414,1415,1421,1427,1432,1438],{},[174,1416,1417,1420],{},[156,1418,1419],{},"Verifica della catena di certificati:"," il client verifica la catena di certificati, accertando che ogni certificato della catena sia firmato da un'autorità di certificazione (CA) attendibile. La catena parte dal certificato del server e termina in un certificato radice attendibile.",[174,1422,1423,1426],{},[156,1424,1425],{},"Corrispondenza del nome di dominio:"," il client controlla che il Common Name (CN) o il Subject Alternative Name (SAN) del certificato corrisponda al nome di dominio del server. Questo garantisce che il certificato sia destinato al server a cui il client si sta connettendo.",[174,1428,1429,1431],{},[156,1430,1407],{}," il client verifica la firma digitale presente sul certificato utilizzando la chiave pubblica della CA emittente. Questo garantisce che il certificato non sia stato manomesso e sia stato effettivamente emesso da una CA attendibile.",[174,1433,1434,1437],{},[156,1435,1436],{},"Periodo di validità del certificato:"," il client controlla il periodo di validità del certificato per accertare che sia attualmente valido e non scaduto.",[174,1439,1440,1402],{},[156,1441,1442],{},"Controllo dello stato di revoca:",[164,1444,1446],{"id":1445},"perché-la-proprietà-è-importante-se-si-è-già-verificato-che-il-certificato-è-attendibile","Perché la proprietà è importante se si è già verificato che il certificato è attendibile?",[152,1448,1449,1452],{},[156,1450,1451],{},"Validità e affidabilità del certificato:"," questo passaggio accerta che il certificato sia stato emesso da un'autorità di certificazione (CA) attendibile, che rientri nel proprio periodo di validità e che non sia stato revocato. Conferma che il certificato è legittimo e non è stato manomesso.",[152,1454,1455,1458],{},[156,1456,1457],{},"Verifica dell'identità del server:"," anche se un certificato è valido e attendibile, occorre confermare che appartenga al server a cui ci si sta connettendo. Questo comporta la verifica che il Common Name (CN) o il Subject Alternative Name (SAN) del certificato corrisponda al nome di dominio del server. Il passaggio garantisce che il certificato sia destinato a quel server specifico e previene gli attacchi man-in-the-middle, in cui un attaccante potrebbe presentare un certificato valido per un dominio diverso.",[164,1460,1462],{"id":1461},"con-quali-due-metodi-il-client-risponde-a-questa-domanda-quali-sono-i-due-esiti-possibili-per-ciascun-metodo","Con quali due metodi il client risponde a questa domanda? Quali sono i due esiti possibili per ciascun metodo?",[257,1464,1465,1492],{},[174,1466,1467,1470,1471,1474,1477,1478],{},[156,1468,1469],{},"Verifica tramite Domain Name System (DNS):"," il client controlla che il Common Name (CN) o il Subject Alternative Name (SAN) del certificato corrisponda al nome di dominio del server. ",[1472,1473],"br",{},[156,1475,1476],{},"Esito",":",[171,1479,1480,1486],{},[174,1481,1482,1485],{},[156,1483,1484],{},"Corrispondenza",": se i nomi coincidono, il client può proseguire con la connessione, certo che il certificato sia destinato a quel server. ",[174,1487,1488,1491],{},[156,1489,1490],{},"Mancata corrispondenza",": se i nomi non coincidono, il client con ogni probabilità interrompe la connessione o mostra un avviso, segnalando un potenziale rischio per la sicurezza.",[174,1493,1494,1497,1498,1500,1477,1502],{},[156,1495,1496],{},"Verifica tramite Public Key Infrastructure (PKI):"," il client verifica la firma digitale presente sul certificato utilizzando la chiave pubblica dell'autorità di certificazione (CA) emittente. ",[1472,1499],{},[156,1501,1476],{},[171,1503,1504,1510],{},[174,1505,1506,1509],{},[156,1507,1508],{},"Firma valida",": se la firma è valida, si conferma che il certificato non è stato manomesso ed è stato emesso da una CA attendibile.",[174,1511,1512,1515],{},[156,1513,1514],{},"Firma non valida:"," se la firma non è valida, il client interrompe la connessione o mostra un avviso, segnalando che il certificato potrebbe essere compromesso o fraudolento.",[164,1517,1519],{"id":1518},"che-cosa-determina-quale-metodo-viene-utilizzato","Che cosa determina quale metodo viene utilizzato?",[152,1521,1522],{},[156,1523,1469],{},[171,1525,1526,1532],{},[174,1527,1528,1531],{},[156,1529,1530],{},"Utilizzo",": questo metodo viene sempre impiegato nell'ambito dell'handshake TLS. Il client confronta il Common Name (CN) o il Subject Alternative Name (SAN) del certificato con il nome di dominio del server per verificarne la corrispondenza.",[174,1533,1534,1537],{},[156,1535,1536],{},"Fattori determinanti:"," si tratta di una parte standard del protocollo TLS, eseguita automaticamente dal client quando stabilisce una connessione sicura.",[152,1539,1540],{},[156,1541,1496],{},[171,1543,1544,1549],{},[174,1545,1546,1548],{},[156,1547,1530],{},": anche questo metodo viene sempre impiegato durante l'handshake TLS. Il client verifica la firma digitale presente sul certificato utilizzando la chiave pubblica dell'autorità di certificazione (CA) emittente.",[174,1550,1551,1553],{},[156,1552,1536],{}," si tratta di un'altra parte standard del protocollo TLS. Il client esegue automaticamente questo controllo per accertare che il certificato sia valido e non sia stato manomesso.",[147,1555,1557],{"id":1556},"quali-certificati-deve-inviare-il-server-al-client","Quali certificati deve inviare il server al client?",[152,1559,1560],{},"Durante l'handshake TLS il server dovrebbe inviare al client i certificati seguenti:",[171,1562,1563,1569],{},[174,1564,1565,1568],{},[156,1566,1567],{},"Certificato di entità finale:"," è il certificato del server stesso, che ne dimostra l'identità al client.",[174,1570,1571,1574],{},[156,1572,1573],{},"Certificati intermedi:"," questi certificati collegano il certificato di entità finale al certificato radice attendibile. Contribuiscono a costruire una catena di fiducia dal certificato del server fino a un certificato radice attendibile.",[147,1576,1578],{"id":1577},"che-cosa-sono-i-certificati-domain-validation-ed-extended-validation","Che cosa sono i certificati Domain Validation ed Extended Validation?",[152,1580,1581,1584],{},[156,1582,1583],{},"I certificati Domain Validation (DV)"," sono un tipo di certificato TLS per il quale l'autorità di certificazione (CA) verifica che il richiedente abbia il controllo del dominio. Di norma questo avviene:",[171,1586,1587,1590,1593],{},[174,1588,1589],{},"Rispondendo a un'email inviata al contatto amministrativo del dominio.",[174,1591,1592],{},"Aggiungendo un record DNS TXT.",[174,1594,1595],{},"Caricando un file sul server web.",[152,1597,1598],{},[156,1599,1600],{},"Caratteristiche principali:",[171,1602,1603,1606,1609],{},[174,1604,1605],{},"Emissione rapida: possono essere emessi rapidamente, spesso nel giro di pochi minuti, perché richiedono una verifica minima.",[174,1607,1608],{},"Sicurezza di base: forniscono la cifratura e una garanzia di base che il dominio sia controllato dal soggetto che richiede il certificato.",[174,1610,1611],{},"Convenienza: spesso sono più economici o persino gratuiti, il che li rende accessibili per siti web di piccole dimensioni e progetti personali.",[152,1613,1614,1617],{},[156,1615,1616],{},"I certificati Extended Validation (EV)"," sono certificati TLS di livello superiore, che richiedono un processo di verifica più rigoroso. La CA verifica l'esistenza legale, fisica e operativa del soggetto che richiede il certificato. Questo comprende:",[171,1619,1620,1623,1626],{},[174,1621,1622],{},"La conferma dell'identità e dello stato giuridico del soggetto.",[174,1624,1625],{},"La verifica della presenza fisica e operativa del soggetto.",[174,1627,1628],{},"L'accertamento che il soggetto abbia il diritto esclusivo di utilizzare il dominio.",[152,1630,1631],{},[156,1632,1600],{},[171,1634,1635,1641,1647],{},[174,1636,1637,1640],{},[156,1638,1639],{},"Garanzia elevata:"," offre agli utenti il massimo livello di fiducia e garanzia, perché comporta controlli approfonditi.",[174,1642,1643,1646],{},[156,1644,1645],{},"Indicatori visibili:"," in alcuni browser i certificati EV mostravano il nome dell'organizzazione nella barra degli indirizzi, anche se oggi è meno comune.",[174,1648,1649,1652],{},[156,1650,1651],{},"Fiducia rafforzata:"," ideali per i siti web che trattano informazioni sensibili, come gli istituti finanziari e i siti di e-commerce.",[164,1654,1656],{"id":1655},"quali-sono-più-sicuri"," Quali sono più sicuri?",[152,1658,1659],{},"I certificati Extended Validation (EV) sono generalmente considerati più sicuri dei certificati Domain Validation (DV), per via del rigoroso processo di verifica a cui sono sottoposti. Ecco un confronto:",[152,1661,1662],{},[156,1663,1664],{},"Certificati Domain Validation (DV)",[171,1666,1667,1673,1679],{},[174,1668,1669,1672],{},[156,1670,1671],{},"Livello di verifica:"," viene verificato solo il controllo del dominio.",[174,1674,1675,1678],{},[156,1676,1677],{},"Sicurezza:"," forniscono cifratura e garanzie di base.",[174,1680,1681,1684],{},[156,1682,1683],{},"Caso d'uso:"," adatti a siti web personali, blog e piccole imprese.",[152,1686,1687],{},[156,1688,1689],{},"Certificati Extended Validation (EV)",[171,1691,1692,1697,1702],{},[174,1693,1694,1696],{},[156,1695,1671],{}," viene verificata l'esistenza legale, fisica e operativa del soggetto.",[174,1698,1699,1701],{},[156,1700,1677],{}," offrono un livello più elevato di fiducia e garanzia, grazie ai controlli approfonditi.",[174,1703,1704,1706],{},[156,1705,1683],{}," ideali per istituti finanziari, siti di e-commerce e qualsiasi sito web che tratti informazioni sensibili.",[152,1708,1709],{},[156,1710,1711],{},"Perché i certificati EV sono più sicuri:",[171,1713,1714,1720,1726],{},[174,1715,1716,1719],{},[156,1717,1718],{},"Controlli approfonditi:"," i certificati EV richiedono una verifica estesa, che rende più difficile ottenerli a soggetti malintenzionati.",[174,1721,1722,1725],{},[156,1723,1724],{},"Indicatori di fiducia:"," benché oggi sia meno comune, i certificati EV mostravano il nome dell'organizzazione nella barra degli indirizzi del browser, offrendo agli utenti una garanzia visibile.",[174,1727,1728,1731],{},[156,1729,1730],{},"Garanzia più elevata:"," il processo di verifica dettagliato assicura che il soggetto dietro il certificato sia legittimo, riducendo il rischio di phishing e di altri attacchi.",[147,1733,1735],{"id":1734},"come-funziona-la-revoca-con-locsp-stapling","Come funziona la revoca con l'OCSP stapling",[152,1737,1738],{},"L'OCSP stapling migliora il processo OCSP standard riducendo la latenza e aumentando la riservatezza. Ecco come funziona:",[257,1740,1741,1747,1753,1759,1765],{},[174,1742,1743,1746],{},[156,1744,1745],{},"Il server richiede una risposta OCSP:"," il server web richiede periodicamente lo stato di revoca del proprio certificato all'OCSP responder, un server gestito dall'autorità di certificazione (CA). La richiesta avviene in background e non a ogni connessione del client.",[174,1748,1749,1752],{},[156,1750,1751],{},"L'OCSP responder fornisce la risposta:"," l'OCSP responder restituisce una risposta OCSP firmata e con marca temporale che indica lo stato del certificato, ad esempio \"good\", \"revoked\" oppure \"unknown\". Il server mette la risposta in cache.",[174,1754,1755,1758],{},[156,1756,1757],{},"Handshake TLS con risposta allegata:"," quando un client, ad esempio un browser web, avvia una connessione verso il server, il server include la risposta OCSP memorizzata in cache nell'handshake TLS. Questo è ciò che si intende per \"stapling\" della risposta all'handshake.",[174,1760,1761,1764],{},[156,1762,1763],{},"Il client verifica la risposta OCSP:"," il client verifica la risposta OCSP allegata. Poiché la risposta è firmata dalla CA, il client può fidarsi della sua validità. Se la risposta indica che il certificato è revocato, il client non stabilisce una connessione sicura.",[174,1766,1767,1770],{},[156,1768,1769],{},"Aggiornamenti periodici:"," il server continua ad aggiornare periodicamente la risposta OCSP in cache, così da avere sempre a disposizione uno stato aggiornato da fornire durante l'handshake TLS.",[152,1772,1773],{},"Questo processo riduce la necessità per i client di effettuare richieste OCSP separate, migliorando così prestazioni e riservatezza.",{"title":434,"searchDepth":435,"depth":435,"links":1775},[1776,1784,1785,1788],{"id":1353,"depth":435,"text":1354,"children":1777},[1778,1779,1780,1781,1782,1783],{"id":1357,"depth":440,"text":1358},{"id":1375,"depth":440,"text":1376},{"id":1411,"depth":440,"text":1412},{"id":1445,"depth":440,"text":1446},{"id":1461,"depth":440,"text":1462},{"id":1518,"depth":440,"text":1519},{"id":1556,"depth":435,"text":1557},{"id":1577,"depth":435,"text":1578,"children":1786},[1787],{"id":1655,"depth":440,"text":1656},{"id":1734,"depth":435,"text":1735},{"lang":461,"seoTitle":1790,"titleClass":462,"socialimg":1791,"blogtitlepic":1792,"customExcerpt":1793,"keywords":1794,"maxContent":472},"Transport Layer Security (TLS): casi d'uso e convalida dei certificati","/blog/heads/header-scepman-use-cases-certificates.png","header-scepman-use-cases-certificates.png","Proteggete il vostro sito web e i vostri utenti con certificati TLS che verificano i server, costruiscono fiducia tramite le catene di certificati e garantiscono connessioni sicure e cifrate.","certificati TLS, Transport Layer Security, casi d'uso dei certificati, convalida dei certificati TLS, catena di fiducia dei certificati, certificati DV, certificati EV, autenticazione dei server, connessioni sicure, OCSP stapling","/glossary/use-cases-for-certificates",{"title":1348,"description":434},"glossary/use-cases-for-certificates","He9cAiMrgjfOJui4jzFUnQfXCCf7exbLKyqE3q4QBQY",{"list":138,"authors":142},1790098990143]