[redhat 8] ssl-certificates voor sendmail + apache

Pagina: 1
Acties:

  • DPLuS
  • Registratie: April 2000
  • Niet online
N.a.v. mijn vorige topics:
[rml][ outlook express 6 & SSL] Secure POP3 irri-notice[/rml]
[rml][ redhat 8] eigen Certification Authority[/rml]
nu mijn volgende vraag:

Ik heb nu dus mijn eigen CA-certificaat, geconverteerd naar een DER-bestand en dit bestand geimporteerd naar mijn eigen pc.

So far, so good.

Maar nu is het probleem dat ondanks dat ik mijn eigen root-ca-certificaat op mijn pc geinstalleerd heb, Outlook Express (bij smtp + pop3 over ssl) en Internet Explorer (bij https) toch blijven zeuren dat de certificaten niet vertrouwd kunnen worden.

Zover ik het begrijp na het lezen van verschillende howto's, moet ik nu ook nieuwe certificaten maken voor apache en sendmail, aangezien ze nu nog gebruik maken van de standaard geinstalleerde certificaten.

De certificaten die Apache gebruikt zijn:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[root@anaconda conf]# pwd
/etc/httpd/conf
[root@anaconda conf]# tree
.
|-- Makefile -> ../../../usr/share/ssl/certs/Makefile
|-- httpd.conf
|-- magic
|-- ssl.crl
|   `-- Makefile.crl
|-- ssl.crt
|   |-- Makefile.crt
|   `-- server.crt
|-- ssl.csr
|-- ssl.key
|   `-- server.key
`-- ssl.prm

5 directories, 7 files


Kortweg: apache gebruikt server.crt en server.key.

stukje van ssl.conf:
-----------------------------------------------------------------
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key

#SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca-bundle.crt
--------------------------------------------------------------------


Moet het certificaat dat ik zelf gegenereerd heb als CA nu niet in de plaats komen van die server.key?
Zo ja, welk bestand moet ik dan precies gebruiken en naar welk output formaat moet ik het dan converteren?
En die server.crt, welk bestand moet ik daarvoor gebruiken?

En in redhat staat ook standaard dit bestand:

/usr/share/ssl/cert.pem , dit is een symlink naar ./certs/ca-bundle.crt,
ik heb gezien dat dit bestand alle public certs van Certificate Authorities bevat, maar 2 dingen: A) wat moet ik met dit bestand doen? 2) Waar dient het precies voor?
Kan ik deze optie gewoon uncommenten in ssl.conf?: #SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca-bundle.crt
Of moet ik in dit bestand misschien mijn eigen CA ook toevoegen?

OK, tot zover de apache vraagjes, nu sendmail:

Ik gebruik dus smtp en pop3 over ssl.
En ook al heb ik mijn eigen root-ca cert geimporteerd, outlook blijft zeuren over de onbetrouwbaarheid van mijn certificaat, dus ik vermoed dat ik nog wat certificaten moet wijzigen van sendmail.

O.a.: in een howto werd uitgelegd dat er een bestand "sendmail.pem" moet staan in /usr/share/ssl/certs.

Want in sendmail.mc moesten deze regels ook toegevoegd worden:

define(`confCACERT_PATH',`/usr/share/ssl/certs')
define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt')
define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem')
define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem')

Sendmail.pem kon je aanmaken met #make sendmail.pem
Maar nu vermoed ik dat dit bestand niet helemaal gerelateerd is aan mijn eigen CA-certificaat.
Moet ik dit bestand sendmail.pem misschien nog signen met mijn eigen server key ofzo?

En waarom staat deze regel er eigenlijk in:
define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt')

Wat moet sendmail met dit bestand? En waarom moet deze optie hier wel gedefinieerd worden en in ssl.conf (van apache) niet?

Nog iets over het pop3 certificaat:
Ik meende eerst dat stunnel gebruikt werd om deze ssl verbinding af te werken.
Maar volgens mij zit ik fout, kijk maar eens naar pop3s in /etc/xinetd.d:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@anaconda xinetd.d]# cat pop3s
# default: off
# description: The POP3S service allows remote users to access their mail \
#              using an POP3 client with SSL support such as fetchmail.
service pop3s
{
        disable = no
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/ipop3d
        log_on_success  += HOST DURATION
        log_on_failure  += HOST
}


Zoals je ziet wordt /usr/sbin/ipop3d gewoon gestart als er een verbinding binnenkomt op poort 995 (pop3s).

En zover ik het kon overzien gebruikt pop3 dit certificaat:
/usr/share/ssl/certs/ipop3d.pem

Moet dit certificaat nu ook vervangen worden door mijn eigen gegenereerde server certificate?

Al met al komt het erop neer dat ik bepaalde services op mijn eigen pc wil gebruiken zonder iedere keer die warnings en notices te krijgen over de betrouwbaarheid van de certificaten.
Ik heb al een hoop documentatie gevonden, maar nergens staat het ECHT DUIDELIJK uitgelegd, vooral over wat te doen met de certificaten van apache, sendmail enz, nadat je je eigen CA hebt aangemaakt.
Vandaar dat dit ook een beetje een rommelige post is (excuseer:))

Verwijderd

Voor zover ik het even Q&D doorlees, is het probleem dat je in e windows-machine het public van je CA moet installeren. Dan moet je die nog even op "trusted" zetten, kan ook in IE geloof ik.

Als je nu een connectie opbouwd, kan windows de hierarchie controleren met de trusted-root-ca. (Die dus in je browser / outlook zit). Pas dan klaagt windows niet meer.

Maar volgens mij moet je je ipop3d-s cert ook vervangen.

  • DPLuS
  • Registratie: April 2000
  • Niet online
Ten eerste, het root-CA van mijn eigen server heb ik al geinstalleerd.

Ten tweede:
Maar volgens mij moet je je ipop3d-s cert ook vervangen.
En hier gaat het nu precies over.
Hoe moet ik ze vervangen?
Moet ik gewoon zeggen #make ipop3d.pem ?
Het punt is namelijk dat ik wil weten of ik mijn CA-cert nog ergens voor nodig heb om die andere certificaten mee te genereren of zoiets.
Want in /usr/share/ssl/certs heb ik nu de volgende bestanden staan:
ipop3d.pem, sendmail.pem en imapd.pem.

Bijvoorbeeld de output van ipop3d.pem:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
[root@anaconda certs]# openssl x509 -noout -in ipop3d.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=--, ST=SomeState, L=SomeCity, O=SomeOrganization, OU=SomeOrganizationalUnit, CN=localhost.localdomain/Email=root@localhost.localdomain
        Validity
            Not Before: Oct 25 19:20:45 2002 GMT
            Not After : Oct 25 19:20:45 2003 GMT
        Subject: C=--, ST=SomeState, L=SomeCity, O=SomeOrganization, OU=SomeOrganizationalUnit, CN=localhost.localdomain/Email=root@localhost.localdomain
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:cc:ca:d6:db:40:e1:cb:87:18:f0:03:6b:8f:8b:
                    8d:d0:3d:64:98:8d:bb:0a:87:82:f6:d2:21:d8:82:
                    5d:dc:c1:85:3f:58:a9:1e:c7:e8:a3:1e:fb:31:08:
                    a9:c5:34:15:23:d0:7b:3f:ad:54:f0:29:47:5a:1e:
                    71:f5:59:1a:3a:21:a6:9b:48:a4:c3:af:c3:b5:2d:
                    75:b7:4b:e3:8f:cc:7f:bf:41:ff:28:db:6d:8a:92:
                    06:9c:fa:2a:ed:07:ad:5e:79:9a:be:91:7e:6e:89:
                    3d:38:bf:7b:c3:16:95:e9:aa:26:75:a7:40:e7:01:
                    9d:38:f7:e7:52:c0:32:e7:09
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                70:5E:3F:D5:10:10:E2:1E:24:B8:01:AA:03:F1:21:9E:D4:1C:E8:F2
            X509v3 Authority Key Identifier:
                keyid:70:5E:3F:D5:10:10:E2:1E:24:B8:01:AA:03:F1:21:9E:D4:1C:E8:F2
                DirName:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/Email=root@localhost.localdomain
                serial:00

            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: md5WithRSAEncryption
        78:40:73:cb:ac:76:1b:93:5a:4c:41:95:81:b2:b7:b4:b7:d8:
        a2:45:64:04:03:2b:dc:4d:62:cc:3c:b4:23:88:b7:8e:e9:45:
        67:c3:6d:60:61:32:cd:f5:a4:76:55:36:44:de:1e:6c:31:ec:
        54:65:53:4f:f6:f8:9b:17:9d:fa:ce:42:39:3f:f1:92:0f:fc:
        79:46:ba:de:f9:f9:cf:fb:a6:cc:2f:63:c4:14:db:23:09:a2:
        08:ee:9e:13:f8:7b:28:85:d8:92:f6:5d:d8:bc:6e:78:cb:a6:
        6b:96:e8:32:01:2d:6a:85:43:84:76:ef:cb:47:8b:58:5a:6e:
        77:4b


Zoals je ziet staat er "X509v3 Basic Constraints: CA:TRUE".
Dit betekent toch dat dit certificaat al een self-signed CA is?
Maar dit certificaat (dat bij de standaard distro van Redhat meegekomen is) heeft toch niets te maken met mijn eigen CA of zelfs domein?

Dus mijn vraag nog eens: welke stappen moet ik nu exact ondernemen om de bestaande "dummy"-certificaten opnieuw aan te maken cq. te vervangen?
En dan wel op zo'n manier dat IE dat certificaat ziet als uitgegeven en signed door mijn eigen CA....

  • Guru Evi
  • Registratie: Januari 2003
  • Laatst online: 17-04 13:12
de CN=localhost.localdomain staat er in die key. Probleempje gaat waarschijnlijk zijn dat de key niet aanvaard wordt omdat ie niet van het localdomain (127.0.0.1) komt maar van @mydomain.bleh of van @192.168.1.1
Daar gaat waarschijnlijk je probleem zitten, ik heb hetzelfde voorgehad dus. Dus je moet een domain hebben of tenminste een interne DNS waardoor diegene die het certificaat geeft kan gecontroleerd worden aan de hand van een lookup. Een certificaat kan niet over verschillende domeinen gaan.
Het certificaat moet behalve indien aangevraagd bij VeriSign of Micro$oft of een andere door de client trusted bedrijf eenmaal geaccepteerd worden zoals bij een SSH verbinding. Komt er verandering in de omgeving dan gaat gelijk welke client een melding geven zoals dat het van een ander host of domein komt, dat het ongeldig is of verlopen enz.

Pandora FMS - Open Source Monitoring - pandorafms.org


  • DPLuS
  • Registratie: April 2000
  • Niet online
OK, ik ben er eindelijk uit!

Eerst nieuwe CA aanmaken:

change dir to /usr/share/ssl then:

# misc/CA -newca
# misc/CA -newreq
# misc/CA -sign

Nu houden we 2 belangrijke bestanden over:

/usr/share/ssl/demoCA/cacert.pem ---> Server certificate
/usr/share/ssl/demoCA/private/cakey.pem ---> Server private key

Apache's SSL gebruikt deze 2 bestanden ook:

# cp /usr/share/ssl/demoCA/cacert.pem /etc/httpd/conf/ssl.crt/server.crt
# chmod 600 server.crt

# cp /usr/share/ssl/demoCA/private/cakey.pem /etc/httpd/conf/ssl.key/server.key
# chmod 600 server.key

Pas evt. /etc/httpd/conf.d/ssl.conf aan.

Kopieer nu ook het server certificaat zodat de browser het kan accepteren:

cp /usr/share/ssl/demoCA/cacert.pem /var/www/html/temp/cacert.crt

Restart httpd en ga met je browser naar https://domein.com/temp/cacert.crt en installeer dit certificaat.

Nu certificaten voor imaps, pop3s en smtp(ssl) aanpassen:

Ga naar /usr/share/ssl/certs

Verwijder eerst de passphrase uit de private key:

# openssl rsa -in ../demoCA/private/cakey.pem -out sendmail.pem
# cat ../demoCA/cacert.pem >> sendmail.pem
# cp sendmail.pem ipop3d.pem
# cp sendmail.pem imapd.pem
# chmod 600 *.pem

Zo, nu moet alles naar behoren werken!

Toch weer een nachtje niet voor niets :)

[ Voor 23% gewijzigd door DPLuS op 03-02-2003 07:12 ]