Per prima cosa è necessario scaricare OpenSSL Toolkit, qui trovate la versione per Windows e qui le versioni per linux.

Una volta completata l’installazione consiglio di aggiungere il percorso [OpenSSLFolder]\bin\ all’elenco dei PATH, in modo da porte richiamare le utility da linea di comando in ogni posizione dal prompt dei comandi.

Di seguito verranno descritte le procedure di generazione dei certificati passo a passo tramite linea di comando (prompt dei comandi).

In alternativa è possibile utilizzare un tool che si appoggia ad OpenSSL chiamato XCA, che permette di effettuare tutte le operazioni tramite GUI.

Generarazione della Certification Authority (CA)

Come prima cosa è necessario generare le chiavi per la Certification Authority, ovvero le chiavi che verrano usate per generare firmare tutte le chiavi di cui abbiamo bisogno. Siccome queste chiavi non verrano firmate da una Authority riconosciuta (Verisign, Thawte ecc.) ma da noi stessi, molte applicazioni visualizzeranno degli avvisi per notificare la cosa.

Vediamo ora come procedere alla generazione di una CA:

• Create una cartella in cui posizionare tutte le informazioni della CA (Es. \MyCA)
• Al suo interno consiglio di create tre cartelle (come viene consigliato anche dal questo tutorial) Keys (per le chiavi pubbliche e private generate) Requests (per le richieste di emissione dei certificati) e Certs (per i certificati veri e propri).
• Come prima cosa è necessario generare una chiave con algoritmo RSA e cifratura Triple DES (in alternativa è possibile utilizzare DES o IDEA). La chiave privata (da conservare in luogo sicuro e protetto) verrà salvata all’interno del file ca.key e sarà di 1024 bit (in alternativa è possibile utilizzare 512, 2048, 4076). Il comando (per maggiori informazioni consultare qui) da eseguire è:

openssl genrsa -des3 -out keys/ca.key 1024

• Verrà richiesta una passphrase con cui proteggere la chiave privata da generare. Tale passphrase verrà richiesta tutte le volte che si utilizzata la chiave generata per firmare o cifrare. Lasciandola bianca non verrà richiesta durante l’utilizzo. Si consiglia di utilizzare una passphrase per garantire la sicurezza della propria CA, che sfrutti tutti i canoni di sicurezza per le password. Il file ottenuto avrà una forma simile alla seguente (chiave espressa in base64):

—–BEGIN RSA PRIVATE KEY—–
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,09C9FA8C5DDAE12D

I29lb68jzuR0FFbdQRS6HKaQ7NEJauH689YFRpKKmqvYCCIhDxARRIRkskI4yp9B
IHEGyICcBnEvNiw+Jgm+4nmJsaoJuWFYSVb4qfcrq/7MXUa7hPVHF+hFxuU/uS4q
/INqbcVeH74ivI+rMZr0p4KcXll8fFH/vh+JultcR/tlsN8tc6RtGmE/zrVmubrU
Ufxpt+XgwESnyQqOhXcFxQDwcakQ3lSBll2SQaYBLvCgblJqPGFxfFb7QVyeoQJ0
yaHnzm2aun+gXCuU83BXfgHQUv9uWugsVMModgO/cyDiP9xwfasiYIOdGRCkZFXV
pOskmdtk6s+uYQBXU+TvnUeiYir5J5Ci+yuTOqx/dxQSFvcxjhX5d53+oWlLg+2K
0PHU5M3rzc5ybLREoqX31MOd0f6IFGfV8C8fsyuQoKYFVeeKAUWB0Br9Sg8eBVnA
GyQG4NQlpI+fKrcPLV6×8G+bx8Cns2Zht0TZpMRXT0ZbaEmLRhcK718SroUx5lCo
SdjvLvHD3saUsdNq28Zk0wh8MWXyW60uJmgQPP7dtzMpq5VKXQVAgh8FY+z2VumM
5oZgQXje7YnjVN+esB1NYoMUuXbPZfYmFPTAZEEP5aueRnntjsMa8IildZz5jhWN
c5Yb0L0/OobZfTXa8lVEc2HfJ7dh3mimtVCF6tQzwiUecZmxXaeLmpjbshE8JLPv
tsxPmCPwy1r+eqLlb8nz9SkhhUZoj7wS4BIhtUXdWILWmz8lp/dHdMug/kh9MkoY
fswyGGbI9Z1B6t22ZsjVuAQgmPQ9Sz3Sqr/bhRJnhRtE6/i17opotQ==
—–END RSA PRIVATE KEY—–

• Il passo successivo è di generareil certificato della nostra Certification Authority sfruttando proprio quella chiave privata generata al passo precedente per la firma. Il comando per effettuare l’operazione è

openssl req -new -x509 -days 1001 -key keys/ca.key -out certs/ca.cer

• Verrà creato in nuovo certificato X509 con validità 1001 giorni (modificabile a piacere) sfruttando la chiave ca.key memorizzandolo sul file ca.cer.Durante la fase di generazione del certificato verranno richieste alcune informazioni come Stato, Provincia, Città, Nome, Mail che verranno memorizzate all’interno del certificato.
• L’ultima operazione consiste nel’estrazione del certificato della CA in formato PKCS12, in modo da poter distribuire il certificato e corrispondete chiave pubblica agli utilizzatore dei certificati generati dalla nostra nuova CA. Per evitare che alcuni software segnalino i futuri certificati da noi generati come non affidabili è necessario aggiungere tale PKCS12 alla liste delle Trusted Root Store. Il comando da eseguire sarà:

openssl x509 -in ca.cer -outform DER -out ca.der

Nel caso lo si voglia in formato DER.

La configurazione di NHibernate può essere fatta principalmente in tre modi; vediamo un attimo come realizzarli con alcuni esempi:

• Tramite .Config:

La configurazione è mantenuata all’interno di un una Section custom del file di configurazione dell’applicazione. Prima di tutto bisogna definire la section, che verrà poi utilizzata da NHibernate in questo modo:

<configSections>
  <section name="nhibernate"
           type="System.Configuration.NameValueSectionHandler,
           System, Version=1.0.5000.0, Culture=neutral,
           PublicKeyToken=b77a5c561934e089" />
</configSections>

Una volta impostata la definizione per la configSection è necessario inserire la sezione di configurazione vera e propria. Di seguito riporto un esempio classico di configurazione.

<nhibernate>
  <add key="hibernate.connection.provider"
       value="NHibernate.Connection.DriverConnectionProvider" />
  <add key="hibernate.connection.driver_class"
       value="NHibernate.Driver.SqlClientDriver" />
  <add key="hibernate.dialect"
       value="NHibernate.Dialect.MsSql2005Dialect" />
  <add key="hibernate.connection.connection_string"
       value="Server=.\SQLEXPRESS; Integrated Security=True;
       Database=AdventureWorks;" />
  <add key="hibernate.default_schema" value="dbo" />
</nhibernate>

I primi tre parametri riguardano la tipologia di connessione, utilizzando un DriverConnectionProvieder e il Client per Sql Server (ne esistono un po’ per tutti i principali motori DBMS). Il Dialect indica il particolare dialetto SQL (dal momento che SQL non è proprio identico per ogni DBMS), in questo caso per Sql Server 2005. La ConnectionString anch’essa legata al tipo di DBMS al quale ci si collega (Consultare la documentazione del Driver di connessione specifico). Ed infine nel caso si voglia definire lo schema di default da utilizzare per l’accesso al DB, in questo caso lo standard di SQL server “dbo”.

A livello di codice è necessario, all’avvio di NHibernate, avviare la configurazione, che recupera dal file appena descritto tutti i parametri di cui ha bisogno per effettuare le connessioni al DB.

Configuration configuration = new Configuration();
configuration.AddAssembly("Assembly.Name");

Il metodo AddAssembly non fa altro che indicare l’assembly da cui ricavare le Entity per effettuare il mapping (classi e file .hbm.xml).

• Tramite File hibernate.cfg.xml

In alternativa è possibile utilizzare un file di configurazione specifico di nhibernate chiamato hibernate.cfg.xml; tale file va copiato nella cartella di output dei file compilati e non incluso come risorsa embedded. La struttura di questo file rispecchia le caratteristiche già evidenziate in precedenza, ma con una sintassi leggermente differente.

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
  <session-factory>
    <property name="dialect">
      NHibernate.Dialect.MsSql2005Dialect</property>
    <property name="connection.provider">
      NHibernate.Connection.DriverConnectionProvider</property>
    <property name="hibernate.connection.driver_class">
      NHibernate.Driver.SqlClientDriver</property>
    <property name="connection.connection_string">
      Server=.\SQLEXPRESS; Integrated Security=True;
      Database=AdventureWorks;</property>
    <mapping assembly="Assembly.Name" />
  </session-factory>
</hibernate-configuration>

In questo caso il mapping con assembly contenente le entità è stato specificato direttamente all’interno del file di configurazione; ciò eviterà di dover utilizzare il metodo AddAssembly().

Con questo tipo di soluzione si ha il vantaggio di poter utilizzare l’Xsd (nhibernate-configuration-2.2) fornito con la distribuzione di nhibernate e conseguentemente l’intellisense funzionante durante la scrittura del file. Affinchè venga individuato il file XSD è necessario copiarlo all’interno della cartella [VisualStudioFolder]\Xml\Schemas.

A Livello di implementazione è necessario aggiungere una riga di codice, così come mostrato dall’esempo sottostante:

Configuration configuration = new Configuration();
configuration.Configure();

• Tramite file xml

L’ultima possibilità è quella di utilizzare un file xml, con nome e percorso qualsiasi, con la stessa sintassi già vista per il file hibernate.cfg.xml. Ciò che cambia a livello di codice è che al metodo Configure in questo caso è necessario passare percorso e nome del file di configurazione utilizzato.

Configuration configuration = new Configuration();
configuration.Configure(@"path\filename.xml");