Come creare e gestire un kdb per il certificato di un IBM Http server da riga di comando

Durante uno dei miei ultimi interventi mi sono trovato a gestire l'installaizone di un nuovo certificato su un IHS contenuto in un KDB creato e testato in IHS 8.5.5 FP16.

Dopo aver settato il nuovo KDB alla partenza IHS dava errore generico

Configuration Failed

e non si avviava.

Dopo un rapido check nelle rilasci sono arrivato alla conclusione che il KDB della FP16 non era compatibile con la versione in cui stavo provando ad importarlo, una delle prime della 8.5.5.

Avendo a disposizione il certificato in anche in formato .p12 ho provveduto a ricreare il kdb da linea di comando (ero su un server linux senza accesso GUI) ed importare il certificato.

Per creare e gestire un db potete posizionarvi nella bin del HTTPServer ed utilizzare gskcapicmd.

Per creare un kdb vuoto  e creare un file stash per contenere la password 

 

./gskcapicmd -keydb -create -pw yourPassword -stash -db ../cert/Certificato.kdb

ora che abbiamo il kdb , possiamo importare il certificato 

./gskcapicmd -cert -import -pw yourPassword -target ../cert/Certificato.kdb -file /tmp/certificato.p12    -type pkcs12

Ora per verificare il contenuto del kdb

 ./gskcapicmd -cert  -list -db ../cert/Certificato.kdb -stashed

dovrebbe dare un ritorno simile a 

Certificates found

* default, - personal, ! trusted, # secret key

!       "CN=CertificateAuth Global Root CA, OU=www.CertificateAuth.com, O=CertificateAuth Inc, C=US"

!       "CN=CertificateAuth SHA2 Secure Server CA, O=CertificateAuth Inc, C=US"

-       fqdn.server.com

In questo caso abbiamo 2 certificati intermedi e un certificato per l'host interessato , ma non è settato come certificato di default. 

Per farlo dobbiamo eseguire il seguente comando

./gskcapicmd -cert -setdefault -db ../cert/nuovoCert.kdb -stashed -label fqdn.server.com

ora avremo come output

Certificates found

* default, - personal, ! trusted, # secret key

!       "CN=CertificateAuth Global Root CA, OU=www.CertificateAuth.com, O=CertificateAuth Inc, C=US"

!       "CN=CertificateAuth SHA2 Secure Server CA, O=CertificateAuth Inc, C=US"

*-       fqdn.server.com

dove  * sta a significare che il certificato ha un default e può essere usato senza problemi.

Per approfondire la miriade di opzioni date dal gskcapicmd vi invito a leggere la documentazione IBM.

Come personalizzare la form di login di iBM Forms experience builder

Negli ultimi giorni mi è stato chiesto di personalizzare la form di login di un IBM Forms tramite la sostituzione del CSS associato alla pagina di logn.

Il prodotto di per se non lo prevede in modo agevole, ho quindi preferito ricorrere a settaggi su IBM Http server che pubblicava Forms eseguendo una sovrascrittura del css servito ai browser degli utenti.

Ho trovato e applicato 2 metodi differenti, a seconda della versione del IBM Http server, partendo dal presupposto di avere un nuovo css che contenga tutte le direttive di stile che vogliamo impartire alla login.

IBM Http server >= 8.5.5 FP1

Potete inserire nella configurazione del vh che espone forms questa direttiva:

   SetEnvIf Request_URI ^/forms/open/8.6.2.612/freedom/css/application_login.css skipwas=1
 

questa istruisce HTTP e plugin , di non servire URL indicato tramite il plugin (e quindi Forms) ma di cercare su Http locale il file .

Ho riprodotto nella document root del vh lo stesso percorso forms/open/8.6.2.612/freedom/css/application_login.css  dove ovviamente ho posizionato il file css customizzato.

IBM HTTP < 8.5.5 FP1

In questo potete utilizzare le seguenti direttive

RewriteEngine On

Alias /static/ "/opt/IBM/HTTPServer/www/static/"

RewriteRule ^/forms/open/8.6.2.612/freedom/css/application_login.css$ /static/application_login.css [PT]


la direttiva Alias la potete usare se volete settare un alias che vi puo' venire comodo anche per rewrite future, mentre con la RewriteRule, cambiate il css esposto andando a servire il vostro customizzato pubblicato nella document root.

Nota: il metodo delle rewrite si può ovviamente applicare anche al primo caso.

IBM HTTP server error while loading shared libraries, come risolvere

Lavorando su una SLES 11SP1 , dovevo riavviare un IBM Http server 8, ma quando andavo a dare il comando di restart


 ./httpd -d ../conf/httpd.conf -k  restart

ho visto che non ripartiva con l'errore seguente:

./httpd: error while loading shared libraries: libaprutil-1.so.0: cannot open shared object file: No such file or directory

Dopo un pò di ricerche mi sono imbattuto in un Wiki IBM  dove ho trovato la soluzione:

tramite il comando ldd  si possono verificare le librerie da cui dipende un eseguibile

 ldd ./httpd
        linux-vdso.so.1 =>  (0x00007fff44942000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fc93e845000)
        libaprutil-1.so.0 => not found
        librt.so.1 => /lib64/librt.so.1 (0x00007fc93e63b000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fc93e400000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc93e1e2000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fc93dfde000)
        libexpat.so.0 => not found
        libapr-1.so.0 => not found
        libc.so.6 => /lib64/libc.so.6 (0x00007fc93dc69000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc93eaec000)

Venivano identificate 3 librerie mancanti , quindi ho fatto un search sul filesystem ed ho verificato dove fossero sull file system ( nel mio caso /opt/ibm/HTTPServer/lib ).

Le librerie condivise vengono identificate all'interno del file /etc/ld.so.conf.d che generalmente include tutti i file *.conf all'interno di  /etc/ld.so.conf.d/*.conf

Ho quindi creato il file httpd-lib.conf che includesse il path dove ho trovato le librerie  

• cd /etc/ld.so.conf.d 
• echo /opt/ibm/HTTPServer/lib > httpd-lib.conf

Per rendere effettiva la configurazione, eliminare la cache e riavviare la conf  ldd

• rm /etc/ld.so.cache
• /sbin/ldconfig

dopo una nuova verifica, le librerie sono state tutte identificate

 ldd ./httpd

        libm.so.6 => /lib64/libm.so.6 (0x00007f7308922000)

        libaprutil-1.so.0 => /opt/ibm/HTTPServer/lib/libaprutil-1.so.0 (0x00007f7308808000)

        librt.so.1 => /lib64/librt.so.1 (0x00007f73085ff000)

        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f73083c4000)

        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f73081a6000)

        linux-vdso.so.1 =>  (0x00007fff5ddff000)

        libm.so.6 => /lib64/libm.so.6 (0x00007fb8dd757000)

        libaprutil-1.so.0 => /opt/ibm/HTTPServer/lib/libaprutil-1.so.0 (0x00007fb8dd63d000)

        libdl.so.2 => /lib64/libdl.so.2 (0x00007f7307fa2000)

        librt.so.1 => /lib64/librt.so.1 (0x00007fb8dd434000)

        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fb8dd1f9000)

        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb8dcfdb000)

        libdl.so.2 => /lib64/libdl.so.2 (0x00007fb8dcdd7000)

        libexpat.so.0 => /opt/ibm/HTTPServer/lib/libexpat.so.0 (0x00007fb8dccb5000)

        libapr-1.so.0 => /opt/ibm/HTTPServer/lib/libapr-1.so.0 (0x00007fb8dcb8b000)

        libc.so.6 => /lib64/libc.so.6 (0x00007fb8dc817000)

        /lib64/ld-linux-x86-64.so.2 (0x00007fb8dd9fe000)

        libexpat.so.0 => /opt/ibm/HTTPServer/lib/libexpat.so.0 (0x00007f7307e80000)

è stato quindi possibile riavviare IHS