>Vapreki che moje da se izpolzva, tai kato certificate ne se izdava za >usluga, a za host - triabva uslugite da sa na edin i sasht hostname! >T.e. ako imenata sa www.something.com i mail.something.com, a >certificate e izdaden za www.something.com, to email clientite shte >se jalvat, che certificate ne e validen za mail.something.com.
Pravilno, taka e... Kato dopylnenie samo. Kogato TLS se poddyrzha ot strana na MTA ima dve principno razlichni deistvia po udostoveriavaneto: server i client. Edin MTA e client,kogato predava edno syobshtenie kym drug MTA. Edin MTA e server, kogato priema elektronen poshtenski potok za lokalna ili posledvashta obrabotka. V zavisimost ot tova ima DVA vida udostoverivane na MTA serverite v ramkite na TLS. Pri udostoverivaneto na nivo "client", MTA, koito e v tazi rolia, proveriava certficate-a na servera, s koito ustanoviava sesia. Sled kato se ubedi, che vsichko e nared, priema da se svyrzhe s drugia MTA. Imenno tuk se proveriava i imeto na hosta, koeto e opisano v certificate-a.V syshtoto vreme obache i drugia MTA (koito e server ot gledna tochka na vryzkata) proveriava certificate-a na clienta. Tuk e nuzhno da se napravi edno vazhno utochnenie. Kogato servera proveriava certificate-a na clienta, toi ne izvyrshva proverka na imeto na hosta (obratnoto bi znachelo da se obvyrzhe systemata ot sertificati s in-addr.arpa ierarhichnoto tyrsene). Ako tova ne be taka, to ne bi syshtestuval virtualen hosting. Pri udostoverivaneto na nivo "server", klientyt proveriava i imeto na host na servera, kym koito se svyrzva, a ne samo validnostta na certificate-a. Edin MTA mozhe da operira s dva certificate-a. Ediniat toi mozhe da izpolzva, kogato e v roliata na server, a drugia, kogato e v roliata na client. Serverskia certificate e obvyrzan s imeto na hosta, no tova ne e zadylzhitelno da e taka za clientskia certificate (tova mezhdu drugoto stana iasno i malko po-gore pri obiasniavane na principa na deistvie v dvete situacii). Ako edin client se opitva da se svyrzhe sys server i pri proverka na certificate-a stane iasno, che certificatyt na servera e nevaliden, vypreki, che nosi v poleto za ime imeto na hosta, to iavno ima sluchai na IP izmama. ============= *** =============== Configuration ============= *** =============== V m4 prototipa na sendmail.cf, faila sendmail.mc se pravi slednoto razgranichenie za certificatite izpolzvani za client i za server configuraciata na MTA dnl dnl Tova sa redovete, koito zadavat certificatite i key za servera define(`confSERVER_CERT',`/usr/share/ssl/certs/host.cert')dnl define(`confSERVER_KEY',`/usr/share/ssl/certs/host.key')dnl dnl dnl a tova sa tezi, koito zadavat configuraciata na clienta define(`confCLIENT_CERT',`/usr/share/ssl/certs/mta.cert')dnl define(`confCLIENT_KEY',`/usr/share/ssl/certs/mta.key')dnl ============= *** =============== Log ============= *** =============== Eto edna ilustracia na tova, kakvi zapisi v zhurnalnia file na Sendmail se praviat za vsiaka TLS sesia. Eto kak MTA priema TLS sesia ot domashno baziran klient, obtabotva ia i ia izprashta kym drug server: Mar 19 23:22:04 lcpe sendmail[10459]: NOQUEUE: connect from Mandrake.nat-lan.lcpe.pip.digsys.bg [193.68.191.198] Mar 19 23:22:04 lcpe sendmail[10459]: STARTTLS=server, relay=Mandrake.nat-lan.lcpe.pip.digsys.bg [193.68.191.198], version=TLSv1/SSLv3, verify=OK, cipher=EXP1024-RC4-SHA, bits=128/56 Mar 19 23:22:04 lcpe sendmail[10459]: STARTTLS=server, cert-subject=/C=BG/ST=Sofia/L=Sofia/O=LCPE,+20University+20of+20Sofia/OU=LCPE+20Staff/CN=Vesselin+20Kolev /[EMAIL PROTECTED], cert-issuer=/C=BG/ST=Sofia/L=Sofia/O=LCPE,+20University+20of+20Sofia/OU=Net+20Division/CN=Vesselin+20Kolev/[EMAIL PROTECTED] # # STARTTLS=server ukazva na tova, che Sendmail uchastva v TLS sesia kato server # sled cipher e opianieto na izpolzvania kodirash algorithm # cert-subject opisva poletata na X.509 certificate ot strana na clienta # cert-issuer opisva poletata na X.509 certificate na izdatelia na certificate na clienta. # Nai-otgore stoi "verify=OK", koeto znachi, che certificate-a na clienta e potvyrden kato validen # Interesnoto tuk e, che clientyt ne e MTA, a e nai-obiknoven Netscape Messenger 4.78 nastroen # da izpolzva PKCS#12 # Mar 19 23:22:04 lcpe sendmail[10459]: h2JLLpAh010459: from=<[EMAIL PROTECTED]>, size=331, class=0, nrcpts=1, msgid=<[EMAIL PROTECTED]>, proto=ESMTP, daemon=MTA, relay=Mandrake.nat-lan.lcpe.pip.digsys.bg [193.68.191.198] Mar 19 23:22:04 lcpe sendmail[10461]: h2JLLpAh010459: SMTP outgoing connect on eth-out.backbone-1.lcpe.uni-sofia.bg Mar 19 23:22:04 lcpe sendmail[10461]: STARTTLS=client, init=1 Mar 19 23:22:04 lcpe sendmail[10461]: STARTTLS=client, start=ok Mar 19 23:22:04 lcpe sendmail[10461]: STARTTLS=client, relay=ns.lcpe.uni-sofia.bg., version=TLSv1/SSLv3, verify=OK, cipher=EDH-RSA-DES-CBC3-SHA, bits=168/168 Mar 19 23:22:04 lcpe sendmail[10461]: STARTTLS=client, cert-subject=/C=BG/ST=Sofia/L=Sofia/O=LCPE,+20University+20of+20Sofia/OU=Server+20Division/CN=eth-in.backbone-1.lcpe.uni-sofia.bg/[EMAIL PROTECTED], cert-issuer=/C=BG/ST=Sofia/L=Sofia/O=LCPE,+20University+20of+20Sofia/OU=Net+20Division/CN=Vesselin+20Kolev/[EMAIL PROTECTED] Mar 19 23:22:06 lcpe sendmail[10461]: h2JLLpAh010459: to=<[EMAIL PROTECTED]>, delay=00:00:02, xdelay=00:00:00, mailer=esmtp, pri=30325, relay=ns.lcpe.uni-sofia.bg. [62.44.103.1], dsn=2.0.0, stat=Sent (h2JMaPsx031783 Message accepted for delivery) Mar 19 23:22:04 lcpe sendmail[10461]: h2JLLpAh010459: done; delay=00:00:02, ntries=1 # # Tuk veche MTA smenia roliata si ot server na client i prepredava poluchenoto ot clienta pismo na drug MTA # cert-subject tuk opisva poletata na X.509 certificate-a na servera, kym koito se predava maila # cert-issuer opisva poletata na X.509 certificate-a na izdatelia na certificate opisan v cert-subject # verify=OK znachi uspeshno udostoveriavane # Eto kak drugia server priema poshtata i ia dostavia localno: (Tylkuvaniata sa podobni ne tezi po-gore, napravete gi za uprazhnenie) Mar 19 23:22:05 lcpe sendmail[31783]: NOQUEUE: connect from eth-out.backbone-1.lcpe.uni-sofia.bg [62.44.103.2] Mar 19 23:33:05 lcpe sendmail[31783]: STARTTLS=server, relay=eth-out.backbone-1.lcpe.uni-sofia.bg [62.44.103.2], version=TLSv1/SSLv3, verify=OK, cipher=EDH-RSA-DES-CBC3-SHA, bits=168/168 Mar 19 23:33:05 lcpe sendmail[31783]: STARTTLS=server, cert-subject=/C=BG/ST=Sofia/L=Sofia/O=LCPE,+20University+20of+20Sofia/OU=Server+20Division/CN=lcpe.pip.digsys.bg/[EMAIL PROTECTED], cert-issuer=/C=BG/ST=Sofia/L=Sofia/O=LCPE,+20University+20of+20Sofia/OU=Net+20Division/CN=Vesselin+20Kolev/[EMAIL PROTECTED] Mar 19 23:33:05 lcpe sendmail[31783]: h2JMaPsx031783: from=<[EMAIL PROTECTED]>, size=601, class=0, nrcpts=1, msgid=<[EMAIL PROTECTED]>, proto=ESMTP, daemon=MTA, relay=eth-out.backbone-1.lcpe.uni-sofia.bg [62.44.103.2] Mar 19 23:33:05 lcpe sendmail[31784]: h2JMaPsx031783: alias <[EMAIL PROTECTED]> => vlk Mar 19 23:33:05 lcpe sendmail[31784]: h2JMaPsx031783: to=<[EMAIL PROTECTED]>, ctladdr=<[EMAIL PROTECTED]> (1002/100), delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30918, dsn=2.0.0, stat=Sent Mar 19 23:33:06 lcpe sendmail[31784]: h2JMaPsx031783: done; delay=00:00:00, ntries=1 Pozdravi Vesselin Kolev ============================================================================ A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html ============================================================================