Ezekkel a lépésekkel beöltődik HTTPS-en keresztül az oldal, de ha lementem a böngészőből a tanúsítványt és beimportálom a böngészőbe a Legfelső szintű megbízhatóak közé, akkor még mindig nem írja azt, hogy hiteles az intranetes oldalam.
Csak a RootCA.cert-et kell beimportálni 'megbízható legfelső szintű'-nek; illetve Unix/Linux esetén a disztribúciófügő könyvtárba telepíteni (a c_rehash -v kimenetének első sora mondja meg), rootként futtatni a 'c_rehash -v', és utána a wget/curl/lynx/openssl-s_client programokkal tesztelni.
Ha beállítom, akkor is azt kapom, hogy nem sikerült ellenőrizni a tanúsítványt, mert a kibocsátó ismeretlen. Tehát sem Chrome, sem Firefox alatt nem látok zöld lakatot (ez r=1 user-es megfogalmazás-:))
Ezen hogy lehet segíteni?
windows? akkor telepitsd a CA-t windows szinten, valamint firefoxban kulon is. lehet Chrome-ban is kell kulon, egy idoben felvette a system szintu dolgokat, de csak bongeszo restart utan. Linuxon szinten bongeszoben kell bepakolni.
Távolról válaszolni erre akkor lehetne, ha precízen, világosan, részletesen le lenne írva minden, amit csináltál. Namostan nyilván ez nem lesz elsőre jó, tehát egy blog-bejegyzésnek kellene lennie, amit lehet szerkesztgetni.
De tényleg alaposan kellene, beleértve olyanokat, hogy pl 'a szerveren OpenSSL-1.1.1a és httpd-2.4.38 van, forrásból telepítve; a httpd.conf-ban ezeket a sorokat helyeztem el SSL-ügyben: xxx; a szerveren lokálisan teszteltem a wget-tel és az openssl/s_clienttel, eredmény: xxx).
Sajnos nem. Ahogy a többiek is mondták, 4.0-tól nincs benne a script, így openssl-el kell legenerálnod a kulcsokat. Egyszerű self-signed certhez mindent megtalálsz a req(1) manualban.
Kérdésem: a keletkezett fájlokat hová kell másolni, illetve a segítségükkel hogyan kell bekonfigolniaz Apache-ot, hogy HTTPS-en keresztül lehessen elérni az intranet szervert, illetve mely keletkező fájlokat kell a kliensekre telepíteni?
Kösz a válaszokat. Tehát nem vettünk külső cert-et, csak self signed certjeim vannak, amiket én generáltam a fenti módon CentOS 7 alatt. A script hat fájlt generál:
Ezta hármat felmásoltam a szerverre, beletettem az Apache virtualhost beállításaihoz.
intranet_RootCA.key
intranet_server.crt
intranet_server.key
Mivel CentOS 7-ben lévő Apache 2.4.6, aminek a conf fájlja rendben van, újraindítás után fut, nem jelez config fájl hibát (a warning-ot leszámítva, hogy a localnetwork-ös egyik DNS nevet nem találja, apoén, hogy a szerver egyik config fájljában sem találtam)
Ezeket importáltam be a Chrome-ba:
intranet_server.pem
intranet_RootCA.pem
Ennek ellenére a kliensböngészőben időtúllépés miatti hibát kapok,ha HTTPS-en keresztül akarom az oldalt elérni (Wordpress alapú).
A log fájlokban az alábbi problémás bejegyzés van:
SSL-warn: Name-based SSL virtual hosts only works for clients with TLS server name indication support (RFC 4366)
Szerintem e miatt nem jelenik meg a kliensben a böngészőn az oldal.
Azért szenvedek, mert az intranet szerverünket belülről kell ellátni tanúsítvánnyal (illetve a tűzfalon átengedett tartományokból láthatják), amihez a Let's Encrypt tudtommal nem jó.
Egyébként csináltam Root CA-t, intermediate és domainre vonatkozó 3 szintűt. Apache-ot bekonfigoltam. Most csinálom az OCSP-t. Annyi hátránya van, hogy nincs zöld lakat:)). Létrehoztam jelszavazott PFX-et aminek a terjesztésének megoldásán goldolkodom: hogyan lehet Win 7 és Win 10 alá távolról telepíteni a Windows saját tanúsítványtárába (találtam PowerShell megoldást, de nem akar működni), illetve a távoli gépre telepített Firefox és Chrome böngészők alá betenni anélkül, hogy a felhasználónak bármilyen interakciójára szükség lenne a bejelentkezésén kívül (Zenworks környezet).
Azért szenvedek, mert az intranet szerverünket belülről kell ellátni tanúsítvánnyal (illetve a tűzfalon átengedett tartományokból láthatják), amihez a Let's Encrypt tudtommal nem jó.
De, jó, ha a domain név, amiben az egész lakik, hivatalosan is bejegyzett domainetek. A kulcsszó, amit keresel: dns validation
"kliensböngészőben időtúllépés miatti hibát kapok,ha HTTPS-en keresztül akarom az oldalt elérni"
Az apache hallgat-e a 443-as tcp porton (fuser -van tcp 443, vagy netstat -tlpn | grep 443)? Ha nem, akkor tessen felkonfigurálni, hogy hallgasson ott is. Ha igen, akkor egy firewall-cmd --zone=public --permanent --add-service=https && firewall-cmd --reload is célszerű, mert default-ban megy a firwalld, de a https (443-as tcp-port) nincs a nagyvilág felé kinyitva.
Update: loalhoston látom, hogy ott van az ssl-es port, tehát tippre a firewalld kaszálja el távolról a kapcsolódást, úgyhogy azt kalapáld ki.
Ilyenkor egyébként mindkét oldalon érdemes lehet tcpdump-ot nézni, hogy a kapcsolat meddig jut el, milyen állapotban áll meg, és persze a szerveren nézni az apache logjait, hogy eljut-e az apache-ig a kérés, vagy sem (szerintem nem, ergo valahol "hamarabb" hal el).
Hozzászólások
ennyire ne tolongjatok..
Pont ma kellett nekem is, hát összeírtam, hogy meglegyen:
SSL turbo howto
Step 1: Generate a Private Key:
#openssl genrsa -des3 -out server.key 1024
Step 2: Generate a CSR (Certificate Signing Request):
#openssl req -new -key server.key -out server.csr
Step 3: Remove Passphrase from Key
#cp server.key server.key.org
#openssl rsa -in server.key.org -out server.key
Step 4: Generating a Self-Signed Certificate
#openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Step 5: Installing the Private Key and Certificate
#cp server.crt /usr/local/apache/conf/ssl.crt
#cp server.key /usr/local/apache/conf/ssl.key
Step 6: Configuring SSL Enabled Virtual Hosts (put these lines in an apache conf file)
SSLEngine on
SSLCertificateFile /usr/local/apache/conf/ssl.crt/server.crt
SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/server.key
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
Step 7: Restart Apache and Test
#apache2ctl restart
test listening:
#netstat -tna | grep 443
Üdv!
Ezekkel a lépésekkel beöltődik HTTPS-en keresztül az oldal, de ha lementem a böngészőből a tanúsítványt és beimportálom a böngészőbe a Legfelső szintű megbízhatóak közé, akkor még mindig nem írja azt, hogy hiteles az intranetes oldalam.
Csak a RootCA.cert-et kell beimportálni 'megbízható legfelső szintű'-nek; illetve Unix/Linux esetén a disztribúciófügő könyvtárba telepíteni (a c_rehash -v kimenetének első sora mondja meg), rootként futtatni a 'c_rehash -v', és utána a wget/curl/lynx/openssl-s_client programokkal tesztelni.
Ha beállítom, akkor is azt kapom, hogy nem sikerült ellenőrizni a tanúsítványt, mert a kibocsátó ismeretlen. Tehát sem Chrome, sem Firefox alatt nem látok zöld lakatot (ez r=1 user-es megfogalmazás-:))
Ezen hogy lehet segíteni?
windows? akkor telepitsd a CA-t windows szinten, valamint firefoxban kulon is. lehet Chrome-ban is kell kulon, egy idoben felvette a system szintu dolgokat, de csak bongeszo restart utan. Linuxon szinten bongeszoben kell bepakolni.
Távolról válaszolni erre akkor lehetne, ha precízen, világosan, részletesen le lenne írva minden, amit csináltál. Namostan nyilván ez nem lesz elsőre jó, tehát egy blog-bejegyzésnek kellene lennie, amit lehet szerkesztgetni.
De tényleg alaposan kellene, beleértve olyanokat, hogy pl 'a szerveren OpenSSL-1.1.1a és httpd-2.4.38 van, forrásból telepítve; a httpd.conf-ban ezeket a sorokat helyeztem el SSL-ügyben: xxx; a szerveren lokálisan teszteltem a wget-tel és az openssl/s_clienttel, eredmény: xxx).
openssl program legenerálja amit akarsz
Celeron-M 1400Mhz, 768M, Debian SID, 2.6.22-rc2
köszi, ez ok, csak gondoltam bejött egy új csomag ennek a helyére ami hasonlóan működik a fentihez képest.
Köszi:)
Sajnos nem. Ahogy a többiek is mondták, 4.0-tól nincs benne a script, így openssl-el kell legenerálnod a kulcsokat. Egyszerű self-signed certhez mindent megtalálsz a req(1) manualban.
Etch-ből érthetetlen okból kivették a szkriptet. Én az "scp" nevű paranccsal tettem elérhetővé a rendszeremben.
Imigyen:
(szoval $OPENSSL="openssl" es a $CRTPEM pedig a pem file neve...)
Sziasztok!
Az alábbi parancssorozattal generálok az intranet szerverhez tanúsítvány fáljokat:
echo "Létező fájlok törlése ..."
rm root*
rm server*
rm v3*
echo "1. lépés"
printf " authorityKeyIdentifier=keyid,issuer\n basicConstraints=CA:FALSE\n keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment\n subjectAltName = @alt_names\n\n [alt_names]\n IP.1 = "$1 > v3.ext
echo "2. lépés"
openssl genrsa -out intranet_RootCA.key 2048
echo "3. lépés"
openssl req -x509 -new -nodes -key intranet_RootCA.key -sha256 -days 1024 -out intranet_RootCA.pem -subj "/C=HU/ST=xxx/L=xxx/O=xxx/OU=xxx/CN=intranet.cegem.hu"
echo "4. lépés"
openssl req -new -sha256 -nodes -out intranet_server.csr -newkey rsa:2048 -keyout intranet_server.key -subj "/C=HU/ST=xxx/L=xxx/O=xxx/OU=xxx/CN=intranet.cegem.hu"
echo "5. lépés"
openssl x509 -req -in intranet_server.csr -CA intranet_RootCA.pem -CAkey intranet_RootCA.key -CAcreateserial -out intranet_server.pem -days 1024 -sha256 -extfile v3.ext
Kérdésem: a keletkezett fájlokat hová kell másolni, illetve a segítségükkel hogyan kell bekonfigolniaz Apache-ot, hogy HTTPS-en keresztül lehessen elérni az intranet szervert, illetve mely keletkező fájlokat kell a kliensekre telepíteni?
1. Ahova szeretnéd de is függően lehet egy /etc/tls... Vagy hasonló ilyesmik tarolasara.
2. Default ssl.conf-ba vagy az adott vhost konfigba erre hivatkozol ami os és Apache verzió függő, de kb mint lenn.
3. Semmit de ha a cert kibocsaltija te vagy, akkor a kibocsaltó tanúsítványát telepíteni, beállítani kell mint megbízható ca.
https://www.digicert.com/csr-ssl-installation/ubuntu-server-with-apache…
Kösz a válaszokat. Tehát nem vettünk külső cert-et, csak self signed certjeim vannak, amiket én generáltam a fenti módon CentOS 7 alatt. A script hat fájlt generál:
Ezta hármat felmásoltam a szerverre, beletettem az Apache virtualhost beállításaihoz.
intranet_RootCA.key
intranet_server.crt
intranet_server.key
Mivel CentOS 7-ben lévő Apache 2.4.6, aminek a conf fájlja rendben van, újraindítás után fut, nem jelez config fájl hibát (a warning-ot leszámítva, hogy a localnetwork-ös egyik DNS nevet nem találja, apoén, hogy a szerver egyik config fájljában sem találtam)
Ezeket importáltam be a Chrome-ba:
intranet_server.pem
intranet_RootCA.pem
Ennek ellenére a kliensböngészőben időtúllépés miatti hibát kapok,ha HTTPS-en keresztül akarom az oldalt elérni (Wordpress alapú).
A log fájlokban az alábbi problémás bejegyzés van:
SSL-warn: Name-based SSL virtual hosts only works for clients with TLS server name indication support (RFC 4366)
Szerintem e miatt nem jelenik meg a kliensben a böngészőn az oldal.
Tudnátok segíteni?
Miért szenvedsz self-signed tanúsítvánnyal, amikor egy domain validateddel (pl: letsencrypt) az egész problémakör 99%-t kihagynád?
Azért szenvedek, mert az intranet szerverünket belülről kell ellátni tanúsítvánnyal (illetve a tűzfalon átengedett tartományokból láthatják), amihez a Let's Encrypt tudtommal nem jó.
Egyébként csináltam Root CA-t, intermediate és domainre vonatkozó 3 szintűt. Apache-ot bekonfigoltam. Most csinálom az OCSP-t. Annyi hátránya van, hogy nincs zöld lakat:)). Létrehoztam jelszavazott PFX-et aminek a terjesztésének megoldásán goldolkodom: hogyan lehet Win 7 és Win 10 alá távolról telepíteni a Windows saját tanúsítványtárába (találtam PowerShell megoldást, de nem akar működni), illetve a távoli gépre telepített Firefox és Chrome böngészők alá betenni anélkül, hogy a felhasználónak bármilyen interakciójára szükség lenne a bejelentkezésén kívül (Zenworks környezet).
Azért szenvedek, mert az intranet szerverünket belülről kell ellátni tanúsítvánnyal (illetve a tűzfalon átengedett tartományokból láthatják), amihez a Let's Encrypt tudtommal nem jó.
De, jó, ha a domain név, amiben az egész lakik, hivatalosan is bejegyzett domainetek. A kulcsszó, amit keresel: dns validation
"kliensböngészőben időtúllépés miatti hibát kapok,ha HTTPS-en keresztül akarom az oldalt elérni"
Az apache hallgat-e a 443-as tcp porton (fuser -van tcp 443, vagy netstat -tlpn | grep 443)? Ha nem, akkor tessen felkonfigurálni, hogy hallgasson ott is. Ha igen, akkor egy firewall-cmd --zone=public --permanent --add-service=https && firewall-cmd --reload is célszerű, mert default-ban megy a firwalld, de a https (443-as tcp-port) nincs a nagyvilág felé kinyitva.
Update: loalhoston látom, hogy ott van az ssl-es port, tehát tippre a firewalld kaszálja el távolról a kapcsolódást, úgyhogy azt kalapáld ki.
Ilyenkor egyébként mindkét oldalon érdemes lehet tcpdump-ot nézni, hogy a kapcsolat meddig jut el, milyen állapotban áll meg, és persze a szerveren nézni az apache logjait, hogy eljut-e az apache-ig a kérés, vagy sem (szerintem nem, ergo valahol "hamarabb" hal el).
Az elején van egy $1, amiről nem világos, hogy milyen IP-cím. No mindegy, egyelőre tegyük fel, hogy 127.0.0.1
Továbbá nem volna rossz, ha a CA neve (CN) különbözne a szerverétől, pl:
Valamennyire működik:
https://hohnstaedt.de/xca/
---------------------------------------------
Support Slackware: https://paypal.me/volkerdi