Il lato oscuro - Il blog di Alessandro Catorcini

Trovare il Page not Found...

Alzi la mano chi non detesta la classica pagina di errore per un HTTP 404 - Page not Found.

La ragione più comune che ho sentito per questa reazione poco entusiastica è che Il messaggio di errore medio passato all'utente è tipicamente inutile: la pagina di errore notifica che si è verificato un problema ma fa poco o niente per correggerlo o per proporre alternative. Si può fare di meglio.

L'ultimo tentativo in ordine di tempo di fare qualcosa per risolvere questo problema è il Web Page Error Toolkit che abbiamo rilasciato oggi.

E' una piccola applicazione, altamente customizzabile e rilasciata in Shared Source che consente di sostituire la pagina statica di errore con una pagina completamente controllata dal sito che la ospita che contiene i risultati di una query a Live Search.

Usarla, cambia la solita pagina di errore di IIS

In una pagina molto più utile:

Dove cercare i risultati (quali domini), quanti risultati mostrare, che lingua utilizzare, se usare o no il correttore ortografico per suggerire alternative, quali messaggi mostrare, sono tutti parametri sotto il controllo totale del webmaster.

La query iniziale è settata da un oggetto che implementa IKeywordExtractor. Il toolkit ne contiene tre esempi, in cui il default usa il contenuto del tag <a> che mandava all'URL fallato. Per esempio, se una pagina conteneva il frammento

<a href="linkRotto.html">Esempio di pagina di errore intelligente</a>

Il keyword extractor di default usa come query iniziale "esempio di pagina di errore intelligente"

Per ora abbiamo rilasciato il codice in ASP.net 2.0 o superiore e IIS 5 o superiore. Presto usciranno le versioni in PHP e Java.

A presto

Tags: .NET Framework, .NET Framework 2.0, ASP.NET, ASP.NET 2.0, ASP.NET 3.5, IIS, Windows Server

Come scrivere in ASP.net un controllo che usa Silverlight solo se è già sul client

L'introduzione di Silverlight ha aperto la porta a design per le UI prima completamente impensabili. Il problema è che non tutti hanno Silverlight, e non tutti vogliono o possono installarla per vedere la tua pagina.

Il problema che dovevo risolvere è "Come si fa a scrivere un controllo in ASP.net che sappia disegnarsi con Silverlight se è installata e abilitata ma che diventi caro vecchio HTML (magari con un po' di AJAX per essere alla moda) se non la trova.

La soluzione è talmente banale da non essere nemmeno divertente.

Tra i vari modi di chiamare Silverlight dentro il browser, il più prosaico è il caro, vecchio Object tag.

Ora, andando a spulciare tra le specifiche dell'HTML, si scopre che se un object tag contiene HTML, questo viene usato nel caso che ci sia un errore nell'istanziare l'oggetto, altrimenti viene ignorato.

Questo vuol dire che se si seguono i seguenti passi:

creare il file XAML o XBAP e aggiungerlo al progetto rinominandolo .slight (per esempio) e assicurarsi che questo file sia compilato come una risorsa dell'assebly del controllo. Questo fa si' che l'applicazione Silverlight sia distribuita insieme ai binari del custom control.

Nel metodo Render(ByVal writer As System.Web.UI.HtmlTextWriter) del controllo polimorfico, aggiungere

With(writer)
.AddAttribute("ID", "SilverlightPlugInID")
.AddAttribute("Data", "data:application/x-silverlight,")
.AddAttribute("Type", "application/x-silverlight")
.AddAttribute("width", "1000px")
.AddAttribute("height", "500px")
.RenderBeginTag("object")
.AddAttribute("name", "source")
.AddAttribute("value", Page.ClientScript.GetWebResourceUrl(Me.GetType(), "NomeDelMioAssembly.NomeDelMioFileXAMLoXBAP.slight"))
.RenderBeginTag("param")
.RenderEndTag() 'param
.AddAttribute("name", "onError")
.AddAttribute("value", "onErrorHandler")
.RenderBeginTag("param")
.RenderEndTag() 'param
.AddAttribute("name", "onResize")
.AddAttribute("value", "onResizeHandler")
.RenderBeginTag("param")
.RenderEndTag() 'param
< Genera qui l'HTML downlevel >
.RenderEndTag() 'object
...
End With

Se si usa Silverlight 1.0, lo script che costituisce l'applicazione Silverlight viene iniettato in uno script block. In questo caso, lo scambio dei dati tra ASP.net e Silverlight può avvenire scrivendo in un tag script gli oggetti JSON che saranno consumati dall'applicazione.

Se si usa Silverlight 2.0, si può scrivere una data island e usare l'HTML bridge.

Questa soluzione funziona con Internet Explorer 7 e 8 beta e con Firefox 2.0 e Safari su Windows.

Tags: Silverlight, XAML

Legionari dell'Impero

Ogni volta che interagisco con qualcuno dall'Italia, una delle domande che prima o poi arrivano è la classica "Ma come ci sei finito a Redmond?", come se per essere qui dovessi avere tre gambe e due teste. Con questo post vorrei sfatare un mito e lanciare una piccola sfida. Lavorare in un product development team in Microsfot a Redmond non è fuori portata. Ma come per vincere alla lotteria, il primo passo è comprare il biglietto, per venire qui bisogna innanzitutto chiederlo. Sul sito di Microsoft Careers si possono vedere le migliaia di posizioni aperte in tutto il mondo. Quando lo feci io (nel secolo scorso ormai, il lontano 1999) il mio CV partì proprio dai form di questo sito. Soltanto nel mio gruppo (Live Search) stiamo cercando più di cento tra developer e developer in test. Siamo a caccia da mesi di developer per l'ottimizzazione della rilevanza per le pagine web in Italiano, che tra gli altri requisiti devono essere fluenti o madrelingua in Italiano. Se avete passione per la tecnologia e se siete disposti a venire fin qui per seguirla, provate. Nel caso abbiate domande, contattatemi direttamente (il mio email personale è {nome}@{cognome}.com dove a nome e cognome dovete sostituire i valori [:)] )

Pizza, topologia e web services

Oggi sono finalmente riuscito a vedere di persona tutta la truppa di ASPItalia &c. qui sotto la pioggia di Seattle dopo quasi tre anni (dal lancio di VS 2005).

La più che dignitosa pizza di Guido, la cameriera dalla scollatura generosa ma discreta, le profonde discussioni tecnico-goliardiche su argomenti vari, dalla topologia alle strategie di typing e verioning sui Web Services hanno reso l'incontro strepitoso.

Arrivederci a presto

Tags: Off Topic

Autopsia di un'applicazione - Terza puntata: l'applicazione che si congela

Se diagnosticare perché un'applicazione si pianta non è sempre facile, diagnosticare perché un'applicazione si congela o va in un loop infinito non lo è praticamente mai. Ci sono due ragioni fondamentali per un application hang:

un loop infinito
un deadlock

mentre individuare il primo è relativamente semplice se avviene nel vostro codice - basta attaccare un debugger, fare un break e leggere lo stack-trace, individuare un deadlock di solito richiede riti voodoo e interventi del mago di fiducia.

Se la fattucchiera non è disponibile, si possono usare altri tool più pratici nell'arsenale del managed developer.

Deadlock: cos'è?

Per avere un deadlock una serie di condizioni deve essere verificata allo stesso tempo:

il processo ha più di un thread
tutti i thread possono accedere a tutte le risorse
le risorse possono essere acquisite da un solo thread alla volta

Il deadlock avviene quando un thread A prende possesso della risorsa 1 (per esempio un socket handle di rete), mentre il thread B prende possesso della risorsa 2 (per esempio un handle di file); se a questo punto il thread A cerca di acquisire la risorsa 2 e il thread B cerca di acquisire la risorsa 1, entrambi i thread si sospenderanno in eterno aspettandosi l'un l'altro.

Anche se la condizione teorica sembra complessa, i deadlock capitano più spesso di quanto sembri. Guardiamo con attenzione le condizioni:

un processo ha più di un thread. Anche se sembra una cosa banale, ogni applicazione scritta con .NET ne ha almeno tre: l'execution thread, il GC thread e il finalizer thread. Se poi si usano timer, c'è anche un timer thread.
tutti i thread possono accedere a tutte le risorse. Questa condizione è vera a meno che non sia applicata una policy nel codice del processo (con eccezioni, come l'STA thread per la UI e la message pump)
Molte risorse non sono intrinsecamente condivisibili (per esempio un file in scrittura)

Se sospetti che la tua applicazione stia esibendo un comportamento compatibile con un deadlock, puoi provare ad usare un tool che Joe Duffy ha scritto usando le hosting API del CLR.

Uno dei comportamenti che possono essere personalizzati tramite queste API è che l'host nativo del CLR può essere notificato ogni volta che un thread è creato, distrutto, sospeso o messo in condizione di essere eseguito. Questo tool, crea un log dei thread presenti nel processo ed esegue un algoritmo di deadlock detection ad ogni cambiamento di stato. Se un deadlock viene identificato, l'host solleva un'eccezione critica che può essere catturata se il processo girava con un debugger attaccato. In questo modo si viene allertati nel momento in cui avviene la presa del lock che genera il deadlock e si può intervenire sul codice.

Il tool e l'eccellente articolo che lo accompagnano si possono scaricare seguendo questo link per l'articolo e questo per il codice

I lettori attenti avranno notato che ho glissato elegantemente sul caso dei loop infiniti nel codice non vostro. Questo è il problema peggiore e sarà oggetto di un post futuro.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5

Autopsia di un'applicazione - seconda puntata gli MDA (Managed Debug Assistants)

A partire dal .NET Framework 2.0, abbiamo introdotto un nuovo strumento per il debugging dei problemi tradizionalmente difficili da diagnosticare.

I cosiddetti MDA (Managed Debugging Assistants) consentono di trattare alcune condizioni come eccezioni così da dare l'opportunità di attaccare un debugger.

Per avere la lista completa degli MDA fate riferimento a questa pagina su MSDN: Diagnosing Errors with the Managed Debugging Assistants

Giusto per dare un'aneddoto che mostra la potenza degli MDA, concentriamo l'attenzione su invalidOverlappedToPInvoke.

Nel 2005, quando le date per il release to manifacturing (RTM) di Visual Studio 2005 e SQL Server 2005 stavano avvicinandosi rapidamente, eravamo alla dispearata ricerca delle cause di un numero anomalo di NT Heap corruptions che lo stress testing stava trovando. Dopo uno stillicidio di due mesi, decidemmo di dedicare l'intero reliability team di entrambi i prodotti a scovare il colpevole. Dopo quattro settimane di immersione full time in memory dump e stack traces, la causa fu trovata in un'innocente funzione che faceva I/O sulla rete attraverso un I/O completion port.

Questo meccanismo dell'OS consente di trasferire il controllo dell'operazione ad un kernel thread e gestisce il messaging con l'applicazione chiamante. I dati sono scambiati attraverso una struct OVERLAPPED allocata dal caller in user mode e scritta dal kernel thread.

Il codice che aveva causato il patatrac non aveva fatto nulla di terribile, ed era formalmente corretto (motivo per cui non lo avevamo trovato immediatamente). L'unico problema era che la struttura OVERLAPPED era allocata sulla GC heap e non era pinned. Questo faceva sì che in certi casi la struttura venisse processata dal garbage collector prima che l'operazione di I/O potesse finire. Quando questo succedeva, il kernel thread scriveva sull'NT Heap handle che gli era stata passata, ma questa memoria era nel migliore dei casi free memory nel GC Heap o qualche altro oggetto (da cui le corruption).

Dopo questa avventura, introducemmo questo MDA, che genera un'eccezione a runtime ogni volta che una struttura OVERLAPPED allocata tramite P/Invoke è passata ad un kernel thread ed è raccolta dal garbage collector prima del tempo.

Per cui, se la vostra applicazione vi sta facendo impazzire e le avete provate tutte, forse un semplice

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework] "MDA"="1"

Può essere utile.

A presto

--Alessandro

Tags: .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, .NET Framework

Autopsia di un'applicazione - prima puntata

Vorrei spendere qualche tempo per parlare di diverse tecniche di diagnosi di un'applicazione. In questa serie di post cominceremo ad analizzare le ragioni per le quali un'applicazione scritta usando il .NET Framework si pianta, presenterò alcuni esempi e pattern che possono causare quei comportamenti e mostrerò alcune tecniche diagnostiche per risalire alle cause prime di problemi profondi (interop signature mismatch e data corruption) molto difficili da diagnosticare con i tool usati comumente.

La prima puntata è una chiaccherata sulle ragioni di morte di un processo che contiene in CLR.

Qualche anno fa, quando si scriveva in C o C++ era facile piantare un programma. Bastava dimenticarsi di assegnare a null un puntatore assegnato a qualcosa che era stato deallocato e il tuo programma si piantava nel modo più creativo. Oggi è molto più difficile trovarsi un una situazione dove un'applicazione scritta nei Framework del XXI secolo sia così fragile.

Quando un'applicazione scritta usando il .NET Framework si pianta, succede uno dei seguenti eventi ritenuti catastrofici dal runtime (in ordine di probabilità):

Un'eccezione sollevata nel codice non è stata gestita
Si è verificata una access violation nell'interop (cioè sei andato a leggere memoria che non è tua)
1. causata dal codice nativo eseguito
2. causata da un errore nel codice di marshalling (signature sbagliata, convenzioni di allocazione non rispettate tra caller e callee, etc.)
3. heap corruption causata da codice nativo
Una risorsa critica per l'esecuzione del programma non è disponibile. Quando questo succede, spesso il programma ha un leak di risorse native (le alloca e non le rilascia mai) o un cattivo uso del Dispose Pattern che lo portano ad una morte prematura per soffocamento. Le risorse la mancanza delle quali può uccidere il processo sono
1. Memoria
2. System Handles
Stack overflow (raro - può succedere se si esagera con la profondità di una query o di una ricorsione)
Un bug nel CLR che causa una access violation (se ne trovate uno dopo il CLR V2 vi pago da bere :-) )

La domanda fondamentale è "Perché un processo viene distrutto in questi casi".

La risposta è di una semplicità disarmante:"Perché è l'unica azione che garantisce la correttezza dell'elaborazione e il più possibile l'integrità dei dati". Se si continua l'esecuzione in questi stati, è garantito che alcuni degli invarianti che il programmatore ha posto come ipotesi per il funzionamento dell'applicazione sono stati violati.

In questo caso sia per ragioni di correttezza sia di sicurezza, il comportamento più sicuro per l'applicazione è terminare il processo e generare un dump utile per scoprire cosa è andato storto.

Questa considerazione è la ragione dietro alla decisione di cambiare il comportamento di default del runtime in caso di una eccezione non gestita. Mentre .NET 1.1 consente di proseguire, .NET 2.0 e superiori termina il processo a meno che non si setti un parametro di configurazione esplicitamente.

La prossima volta parleremo di MDA (Managed Debugging Assistants) uno strumento potente e poco conosciuto per la diagnostica di problemi seri e difficili da identificare altrimenti.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, Pattern

Il CLR in un processo è come Highlander: ce ne può essere soltanto uno

Una delle ragioni principali per le quali il .NET Framework è diventato popolare molto rapidamente è che fa molto per proteggere i programmatori da se stessiò errori come doppi free, access violations, leaks, sono stati ridotti e in certe ipotesi resi impossibili. Purtroppo, il costo di più protezioni si paga con un accesso più ostico ai livelli più bassi del sistema e con il fatto che capire fino in fondo le assunzioni di base che si fanno quando si scrive codice in .NET non è semplice.

Questo è il primo di una serie di posting che parleranno di modi non ovvi in cui le cose possono andare storte, e su come si può uscire da situazioni difficili.

Il primo argomento di cui voglio parlare è una limitazione poco conosciuta, ma dalle conseguenze imprevedibili nei casi in cui si violino i suoi invarianti: quando gira codice di .NET in un processo, può essere caricata solo una versione del CLR, e una volta caricata, non può essere scaricata o fatta ripartire da zero. Solo Silverlight fa eccezione a questa regola e può coesistere con un desktop CLR nello stesso processo.

Quando un'applicazione (per esempio Microsoft Office o Adobe Photoshop) espone un modello di estensibilità tramite COM, questo consente a codice di terze parti (l'add-in) di interagire con le strutture dell'applicazione, spesso all'interno dei confini del processo. E' del tutto possibile (e piuttosto banale) esporre tipi di .NET come oggetti COM. Oppure è piuttosto semplice seguire le ricette che anche alcuni articoli di MSDN presentano per scrivere piccole shim che usano le hosting API del CLR per fare partire codice di .NET nel processo (vedi l'articolo di Siew-Moi Khor e Andrew Whitechapel "Isolating Microsoft Office Extensions with the COM Shim Wizard Version 2.0") - questo consente di aggirare il fatto che senza una shim dedicata non è possibile firmare il codice con Authenticode.

Non c'è nulla di sbagliato nel farlo. Quello dal quale bisogna guardarsi sono le assunzioni che si fanno.

Questo non è un problema quando si ha a che fare con un processo host che è scritto in modo da prevedere che qualcuno degli add-in nel processo potrebbero richiedere di avere un arbitro se ci fossero delle richieste divergenti, ma può creare un problema quasi indebuggabile altrimenti.

Tempo fa mi trovai davanti ad un problema interessante. Un grosso cliente usava un add-in di Excel per fare dei complicati calcoli finanziari, e la potenza di .NET aveva fatto sì che avessero portato tutta l'applicazione da VBA e COM. Eravamo ancora agli albori di VSTO, quindi l'add-in era una semplice shim che chiamava CoreBindToRuntimeEx per caricare in memoria il CLR ed eseguire gli assembly dell'applicazione.

Le performance erano ottime e i risultati della sperimentazione iniziale altamente positivi. Nonappena iniziarono il deploy, però, circa il 40% delle workstation crashava Excel al boot. L'unico rimedio sembrava disinstallare in nuovo add-in. Il problema sembrava essere completamente casuale, presentandosi su macchine con le stesse applicazioni installate.

Dopo un paio di giorni arrivammo alla soluzione: quello che importava era non solo la presenza delle stesse applicazioni, ma l'ordine nel quale erano state installate. Questo perché Excel caricava gli add-in nell'ordine in cui erano stati installati, e uno degli add-in che erano installati da un'altra suite di utility era stato scritto usando .NET 1.1.

La sequenza delle operazioni quindi diventava

Fai il boot di Excel
carica il primo add-in scritto con .NET
carica e fai partire il CLR specificato carica gli assembly richiesti

A questo punto se per caso il CLR caricato e fatto partire era la versione 1.1, l'add-in compilato per 2.0 falliva il load, e l'eccezione non gestita veniva propagata tramite COM fino alla soppressione del processo.

Successivi Service Pack di Office e l'avvento di VSTO hanno oggi risolto questo problema almeno per Office, ma ogni volta che si carica o si usa codice .NET in un processo che non è in grado di arbitrare le versioni del runtime, bisogna ricordarsi di gestire il caso in cui il proprio non sia l'unico add-in che cerca di caricare il CLR nel processo, e che molto probabilmente gli altri non l'hanno fatto ;-)

Per quelli di voi che scrivono applicazioni estensibili tramite COM, se volete supportare veramente add-in scritti usando il .NET Framework dovete scrivere un arbitro per il loader del CLR. Farlo è piuttosto semplice: basta registrare una callback tramite LockCLRVersion e dirottare tutte le chiamate che provano a caricare a fare partire un CLR a passare dal vostro codice di arbitraggio.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5

Smitizzare HTTPS e le infrastrutture a chiave pubblica (PKI)

Per un utente finale, https è pericolosamente simile al cugino http.

In realtà molto di più accade in modo nascosto e capire meglio la differenza aiuterà molto in situazioni in cui sia richiesto di usare https come trasporto sicuro.

Https o http su SSL nacque negli anni '90 come una prima applicazione di SSL per la tramissione sicura di dati. E' visto come uno degli architravi della nascita dell'e-commerce.

Il principio fondamentale su cui SSL si basa è semplice: un client e un server verificano il proprio "pedigree" e si scambiano una chiave di sessione con la quale criptare il traffico tra loro.

Il "pedigree" in questione è costituito da una serie di messaggi criptati e firmati con una coppia di chiavi pubblica/privata contenuti in un certificato.

Smitizziamo un po' il gergo dell'https e dell'SSL

Una chiave è un dato utilizzato come parametro da un algoritmo di crittazione o decrittazione per cifrare o decifrare un insieme di dati. Una chiave può essere parte di una coppia, in cui ciò che è cifrato con una delle chiavi può essere solo decifrato dall'altra, o una chiave a sé stante. Nel primo caso, una delle chiavi della coppia può essere distribuita liberamente (chiave pubblica) e solo chi possiede l'altra (chiave privata) potrà accedere all'informazione cifrata. Nel secondo caso, la chiave deve essere conosciuta da entrambe le parti della conversazione a priori perché ci possa essere una conversazione cifrata.

E' da notare come gli algoritmi di crittazione/decrittazione a chiave pubblica (per esempio RSA) siano ordini di grandezza più lenti degli algoritmi a singola chiave privata (per esempio AES o Blowfish)

Un certificato è l'unione di un'identità (per esempio un nome o l'url di un server) e una coppia di chiavi. Un certificato può essere firmato usando la chiave di un altro certificato.

Una firma digitale è definita come lo hash di un insieme di dati e il nome del principal di un certificato. Una volta che un insieme di dati ha una firma digitale, modificare i dati in qualunque modo rende lo hash diverso da quello contenuto nella firma e quindi rende evidente che i dati sono stati alterati.

A questo punto è ovvio che se uso la mia chiave privata di una coppia di chiavi contenute in un certificato a mio nome per generare lo hash di una firma digitale, questo ha due effetti:

Chi riceve quei dati può verificare la firma con la mia chiave pubblica e certificare che quei dati vengono veramente da me
Chi riceve quei dati può verificare che quei dati non sono stati modificati da nessuno e che sono esattamente gli stessi identici dati che sono stati da me inviati.

a questo punto abbiamo il primo ingrediente per stabilire una connessione sicura.

L'inghippo a questo punto diventa come fare a sapere se la chiave pubblica che ho trovato nel certificato pubblico che mi hai dato è davvero la tua.

Qui entra in gioco il concetto di Public Key Infrastructure (PKI) e di Certification Authority (CA).

Non tutti i certificati sono uguali. Alcuni certificati sono firmati da altri certificati, che sono firmati da altri certificati e così via.

Nel mondo esiste un gruppo di certificati speciali. Sono i cosiddetti Trusted Root (la migliore traduzione che mi viene in mente è le "fonti di fiducia").

Questi certificati sono stati verificati con una procedura rigorosa al di fuori delle normali trasmissioni e i loro possessori si sono impegnati a seguire procedure altrettanto rigorose per emettere e firmare certificati.

La lista di questi trusted root universali si può trovare lanciando MMC e inserendo lo snap-in dei certificati. Nell'albero a sinistra c'è un nodo "Trusted Root Certification Authorities".

Tornando ad un certificato, si chiama catena della fiducia (chain of trust) il fatto che l'atto di firmare un certificato implica certificare il legame tra il nome della risorsa e le chiavi crittografiche. Iterando questo, un certificato che è stato firmato da un root, può essere usato per firmare altri certificati, così trasferendo la verifica implicita che anche questi certificati di secondo o n-esimo livello sono verificati.

Tornando al nostro problema con SSL e HTTPS, per verificare che un client è davvero chi dice di essere e che il server è davvero chi dice di essere la conversazione che avviene è la seguente:

Client "Ciao Server. Sono Pino della Ragioneria. Questo è il mio certificato.° (nota - questo è facoltativo e succede solo se il client usa il certificato per autenticarsi. Talvolta questo si fa per avere connessioni ad alta sicurezza, per esempio quando la chiave privata è registrata su una smartcard)

Server: "Ciao Pino della Ragioneria, il tuo certificato è valido e firmato da qualcuno di cui mi fido, quindi sei davvero tu. Questo è il mio di certificato"

Client: "Server, il tuo certificato è firmato dalla chiave di un certificato di cui mi fido. usando la tua chiave pubblica ho criptato una chiave privata che vorrei usare per questa sessione°

Server: "Pino, ho ricevuto la tua chiave di sessione e ti manderò i dati criptati con essa. Mostra il famigerato lucchetto chiuso nel browser."

Capire come funziona questo handshake è la chiave per tutti i problemi che ho trovato nei forum di ASPItalia attorno a configurare https e i certificati.

In particolare, dove le cose possono andare storte è nella fase in cui il client verifica l'identità del server. Questa fase richiede che il certificato che il server usa per identificarsi si possa ricollegare ad una Trusted Root Certification Authority.

Perché ciò avvenga è necessaria una delle seguenti condizioni:

avete comprato un certificato SSL da una Certification Authority riconosciuta
avete reso la vostra CA fidata presso i client che si collegheranno

Il caso 2 diventa interessante nello scenario in cui si voglia usare https come il trasporto per un web service aziendale che si voglia aprire soltanto a clienti interni. Per fare questo si deve settare IIS con un certificato https generato dalla propria CA e si installa il certificato root della propria CA sui client tra i Trusted Root CA.

Questo ultimo passaggio eviterà che il browser segnali che il certificato usato dal server non è fidato con il famigerato messaggio di warning.

Si può andare oltre, e richiedere che i client si identifichino con un certificato rilasciato dalla stessa CA. Questo consente di integrare un'autenticazione a user-password (qualcosa che sai) con un autenticazione a token (qualcosa che hai).

E' da notare che per installare una nuova Trusted Root CA è necessario essere amministratori della macchina client (ovviamente)

Questo è il mio primo post ospitato dagli amici di ASPItalia. Grazie a Daniele, Stefano, Ricky, Ricciolo e tutti quelli che mi sto dimenticando in questa lista per la cortese ospitalità.

Tags: IIS, Security, Windows Server