GNU date vs BSD date

Pro kotrolu validace SSL certifikátů v Zabbixu jsem se rozhodl použít návod na wiki.zabbix, kde je odkaz na podrobnější autorův web.

Vše by fungovalo, až na malou drobnost a tou je následující příkaz, který je součástí scriptu, porovnávající datum z certifikátu s aktuálním časem. BSD date a GNU date je jiný a parametry jsou jine.

BSD date

date '+%s' --date "Dec 29 23:59:59 2013 GMT"
date: illegal time format
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
            [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format]

Script zext_ssl_check.sh, který používá OpenSSL (openssl s_client) pro zjištění data expirace certifikátu jsem si postupně prošel až jsem narazil na příkaz date. Abych FreeBSD naučil GNU date - gdate, musel jsem doinstalovat následující balíček coreutils.

coreutils-8.20_2    The Free Software Foundation's core utilities

Pak už příkaz dělal co má.

GNU date

gdate '+%s' --date "Dec 29 23:59:59 2013 GMT"
1388361599

Pak už příkaz dělal co má. Na stránce autora jsou dvě verze scriptu pro kontrolu SSL certifikátů. Jedna je z webu a druha je z svn.

Verze s svn vraci jen počet dní do expirace.

./zext_ssl_check.sh edu.mudk.cz 443
290

Verze z webu ma širší použití.

./zext_ssl_cert.sh
usage: ./zext_ssl_cert.sh [-i|-d] hostname port
    -i Show Issuer
    -d Show valid days remaining

./zext_ssl_cert.sh -i edu.mudk.cz 443
Thawte DV SSL CA

./zext_ssl_cert.sh -d edu.mudk.cz 443
290

Ke každému scriptu je extra Template. Použil jsem verzi z svn, ale musel jsem Template modifikovat pro Zabbix 2.0.5. Konkrétně mi External_check nefungoval.

Mnou upravená definice klíče.
zext_ssl_check.sh[{HOST.CONN},{$SSL_PORT}]

V Template bylo. Zkrátka musíme vědět co a jak je kde třeba :-)

zext_ssl_cert.sh[{$SSL_PORT}]

s tím, že varianta

zext_ssl_check.sh[{HOST.CONN}, {$SSL_PORT}]
a
zext_ssl_check.sh[{HOST.CONN} {$SSL_PORT}]

mi nefunovala v Zabbixu 2.0.5.

OpenSSL library error follows - values mismatch

Řešil jsem standartní výměnu SSL certifikátu u webserveru Apache. Po domluvě s osobou, co certifikační řízení řešil u CA Thawte jsem mu vytvořil nové CSR dle zvyklostí.

openssl genrsa -des3 -out www.domena.cz.key 2048
openssl req -new -key www.domena.cz.key -out www.domena.cz.csr
openssl rsa -in www.domena.cz.key -out www.domena.cz.key-decrypt

Posléze jsem certifikáty přenesl na webserver a restartoval jej a ejhle, Apache nenaběhl s hláškou:

[Mon Nov 21 12:36:16 2011] [error] mod_ssl: Init: (www.domena.cz:443) Unable to configure RSA server private key (OpenSSL library error follows)
[Mon Nov 21 12:36:16 2011] [error] OpenSSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

Je vhodné vždy prověřit, zda je modulus stejny u klíče (key), certifikátu (crt) a požadavku (csr)!!!

openssl x509 -noout -text -in www.domena.cz.crt -modulus
openssl rsa -noout -text -in www.domena.cz.key -modulus
openssl req -noout -text -in www.domena.cz.csr -modulus

Muj problem byl v tom, že mi pán zaslal jiný cert, než bylo domluveno :-(

BEAST attack on TLS

Již dříve jsem si sem poznamenával něco o SSL Tunningu na serverech, jako reakce na clánek na root.cz. Nově jsem na SSL Labs narazil na BEAST attack.

Zde je doporučené nastaveni OpenSSL - mod_ssl. Ukázkové video o útoku.

SSLProtocol -all +SSLv3 +TLSv1
SSLCipherSuite RC4-SHA:ALL:!NULL:!aNULL:!eNULL:!ADH:!LOW:!EXP:!MD5
SSLHonorCipherOrder On

SSL Tunning

Po přečtení článku na rootu jsem musel přenastavit často používané defaultní nastaveni SSL u několika webserveru s Apache. Defaultní nastavení je ve prospěch mnoha starších browseru. Ale bezpečnosti nenní nikdy dost a zombie sw má prostě smůlu. Ve článku je zmíněn velmi povedený online nástroj na proveření konfigurace SSL (HTTPS).

https://www.ssllabs.com/ssldb/index.html

Drobným doporučením pro konfiguraci Apache je. Konfiguraci SSL hodně ovlivňují tyto dvě direktivy SSLCipherSuite a SSLProtocol

SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:-MEDIUM
SSLProtocol -all +SSLv3 +TLSv1

Díky RSA007 za nakopnutí v daném tématu.

EV Certifikát od Thawte

Již v minulosti jsem zprovozňoval Extended Validation Certificate na web serveru Apache. Ale to bylo u jiné certifikační autority. Popsané to mám zde.

Postupy pro jednotlivé instalace pro jednotlivé programy jsou zde na stránce Install SSL certificate.

Návod na instalaci na serveru Apache je zde Install Extended Validation Certificate on Apache

Zajimavostí je, že u Thawte musíme vyplnit stahovací formulář a potvrdit pravidla užití kořenových certifikátů, které stáhneme zde. Což se tuším u VeriSign nemuselo.

Nastavení Apache je již obdobné jako u puvodního příspěvku. Důležité jsou opět direktivy SSLCACertificateFile a SSLPassPhraseDialog.

Kontrolu certifikatu na serveru můžeme proveřit pomoci Browseru, nebo z příkazové řádky, pomocí prikazu. Velmi pekný a ucelený návod na OpenSSL je zde.

openssl s_client -connect www.google.com:443

Jak na SSL certifikát Secure Site Pro with EV od VeriSign

Řešil sem vytvoření SSL certifikátu a ověření u certifikační autority dále jen CA VerySign. Jednalo se o tento produkt Secure Site Pro with EV. V minulosti jsem měl zkušenosti s CA Thawte a tak jsem nestudoval všechny podrobnosti a to se mi vymstilo.

CSR jsem jsem si vytvořil následovně.

openssl req -newkey rsa:2048 -sha1 -nodes -keyout private.key -out public.csr

Protože EV certifikát vyžaduje velikost privátního klíče 2048. Takto vytvořený CSR sice bezproblémově prošel certifikací, ale web server Apache odmítal nastartovat natož nahodit 443 virtual. V logu ssl_engine_log se objevovalo toto.

[error] Init: (www.domena.cz:443) Unable to configure RSA server private key (OpenSSL library error follows)
[error] OpenSSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

Po dlouhém hledání a nastudování patřičných návodů k dané chybě, jsem ověřil že modus nesedí (není stejný), což je vyžadováno. Nápomocné jsou tyto příkazy OpenSSL, které načtou informace o klíčí a certifikátu. Další nápověda je zde.

openssl x509 -noout -text -in www.domena.cz.crt-modulus | less
openssl rsa -noout -text -in www.domena.cz.key-modulus | less

Byl jsem tudíž donucen stávající a ověřený klíč Revokovat a vytvořit nové CSR a privátní klíč pomocí doporučených OpenSSL příkazů. Certificate Signing Request (CSR) Generation Instructions - Apache SSL

openssl genrsa -des3 -out www.domena.cz.key 2048
openssl req -new -key www.domena.cz.key -out www.domena.cz.csr

U VeriSign jsem narazil na problém při přepsání klíče.

Revoke and Replace
4) Summary
We are unable to continue with this enrollment for the following reason: eECAS_INSTANT_DN_NOT_MATCH

Dále jsem provedl jen Revoke a manuální přepsání, ale to nikam nevedlo.

2) Summary
We are unable to continue with this enrollment for the following reason:
eECAS_INSTANT_DN_NOT_MATCH

Po kontaktování podpory jsem byl nasměrován na popis chyby. Error: errors.ecas.1 during EV Certificate replacement no a po novém certifikačním požadavku, kde se u platby uvede Order Number na které je vázána již uskutečněná platba.

Pro korektní zprovoznění certifikátu je třeba nakonfigurovat Apache takto. Volba SSLPassPhraseDialog se užije jen v případě, že máme klíč s pass phrase k čemuž nás VeriSign nabádá.

SSLPassPhraseDialog exec:/usr/local/etc/apache22/certi/ssl_pwd.pl
SSLCertificateFile certificates/www.domena.cz.crt
SSLCertificateKeyFile certificates/www.domena.cz.key
SSLCACertificateFile certificates/intermediate.crt
nebo
SSLCertificateChainFile certificates/intermediate.crt

Kdy certifikát expiruje ?

Na tuto otázku je snadná odpověď. V browseru klikneme na zámek u https spojení. Bejvá v browserech v pravo dole. Z okna vlastnosti máme možnost vyčíst informace o certifikátu. Pokud chceme daný udaj zjistit pomocí pžíkazu openssl na příkazové řádce, jednoduchý postup je zde.

Manually check the expiration date of an SSL certificate:

1. Retrieve the certificate.
$ echo "" | openssl s_client -connect server:443 > certificate

2. Check the expiration date of the certificate.
$ openssl x509 -in certificate -noout -enddate
notAfter=Nov 11 23:59:59 2010 GMT

Tak zase za rok :-) Orig návod je zde.

IBM IHS + SSL na Ubuntu

Zprovoznit na IBM IHS HTTP serveru SSL byl docela oříšek. IHS je Apache2 a na něj jsou nalepené IBM moduly např. mod_ibm_ssl nebo mod_was_ap20_http.

První problém nastal při nahrání mod_ibm_ssl, kdy se do error.logu psala tato háška.

SSL0166E: Failure attempting to load GSK library.

Modul vyžaduje v systému přítomnost aplikace GSK toolkit, která je z dílny IBM a bohužel je jen pro podporované systémy využívající RPM. Řešení pro Ubuntu je následující.

cd /opt/IBM/HTTPServer/GSKitImage/
alien -d gsk7bas-7.0-4.14.i386.rpm
dpkg -i gsk7bas_7.0-5.14_i386.deb (prevedeme rpm na deb)

nutné ještě toto, kvuli zavislostem binárek.

apt-get install libstdc++5

Pomocí WAS admina jsem nechal zkopírovát certifikát. Klikat možno zde:

Webové servery > webserver1 > Globální direktivy

Dále jsem se mořil s hláškou:

SSL0263W: SSL Connection attempted when SSL did not initialize

Popovídaní si s dobrým člověkem na telefonu zabralo :-) (postačlo drobné doporučení)

joe /opt/IBM/HTTPServer/conf/httpd.onf
--~--
SSLEnable
SSLServerCert selfSigned
SSLV2Timeout 100
SSLV3Timeout 1000
SSLCipherSpec 35
...
Listen 443
...
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
...
KeyFile "/data/IBM/HTTPServer/keys/webserver1.kdb"
--~--