apache-ssl-certificate

Debian GNU/Linux

Hi!

Debian 4.0r0 alatt ismertek olyan programot ami az apache-ssl-certificate -hez hasonlóan, legenerálja a pem fájlt?

Előre is köszi.

  • 4569 megtekintés

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

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.

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).

( _ventura_ v | 2007. 06. 11., h – 13:08 )

openssl program legenerálja amit akarsz

Celeron-M 1400Mhz, 768M, Debian SID, 2.6.22-rc2

( bigwig | 2007. 06. 11., h – 13:09 )

Etch-ből érthetetlen okból kivették a szkriptet. Én az "scp" nevű paranccsal tettem elérhetővé a rendszeremben.

( apal v | 2007. 06. 11., h – 15:17 )

Imigyen: 


        $OPENSSL req -x509 -days 3650 -newkey rsa:1024 -nodes \
                 -keyout $CRTPEM -out $CRTPEM
        exit 0

(szoval $OPENSSL="openssl" es a $CRTPEM pedig a pem file neve...)

( machobymb v | 2019. 02. 16., szo – 15:01 )

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?

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: 


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=Cegem RootCA"

Valamennyire működik: 


$ openssl s_client -CAfile intranet_RootCA.pem -showcerts -connect 127.0.0.1:443
CONNECTED(00000004)
depth=1 C = HU, ST = xxx, L = xxx, O = xxx, OU = xxx, CN = Cegem RootCA
verify return:1
depth=0 C = HU, ST = xxx, L = xxx, O = xxx, OU = xxx, CN = intranet.cegem.hu
verify return:1