setup STARTTLS with sendmail and openSSL

STEP 1: Enable STARTTLS in sendmail: 1. Install openSSL (http://www.openssl.org) as described in the openSSL’s INSTALL
file. After installation, be sure that the openSSL program is in your path
(cp /usr/local/ssl/bin/openssl /usr/bin), otherwise the CA.pl program does
not work. 2. Create or edit /usr/src/sendmail-8.12.7/devtools/Site/site.config.m4 and
insert the following lines: APPENDDEF(`confINCDIRS’, `-I/usr/local/ssl/include’)
APPENDDEF(`confLIBDIRS’, `-L/usr/local/ssl/lib’)
APPENDDEF(`conf_sendmail_ENVDEF’, `-DSTARTTLS’)
APPENDDEF(`conf_sendmail_LIBS’, `-lssl -lcrypto’) 3. Rebuild and install sendmail with the -c option (see README in
devtools/Site): cd /usr/src/sendmail-8.12.7
./Build -c
./Build install 4. Check to see if sendmail is compiled with STARTTLS: /usr/sbin/sendmail -d0.1 -bp 5. Edit /usr/src/sendmail-8.12.7/cf/cf/sendmail.mc and insert the following
lines: define(`confCACERT_PATH’, `/etc/mail/certs/’)dnl
define(`confCACERT’, `/etc/mail/certs/cacert.pem’)dnl
define(`confSERVER_CERT’, `/etc/mail/certs/cert.pem’)dnl
define(`confSERVER_KEY’, `/etc/mail/certs/key.pem’)dnl
define(`confCLIENT_CERT’, `/etc/mail/certs/cert.pem’)dnl
define(`confCLIENT_KEY’, `/etc/mail/certs/key.pem’)dnl 6. Backup and regenerate /etc/mail/sendmail.cf: cd /etc/mail
cp sendmail.cf sendmail.cf.bak
cd /usr/src/sendmail-8.12.7/cf/cf
./Build sendmail.cf
./Build install-cf 7. Now you have to create three files: cacert.pem (CA certificate), cert.pem
(x.509 certificate, signed by CA) and key.pem (x.509 private key). This is
how you do this: cd /usr/local/ssl/certs
../misc/CA.pl -newca
../misc/CA.pl -newreq-nodes
../misc/CA.pl -sign
mkdir /etc/mail/certs
cp demoCA/cacert.pem /etc/mail/certs
cp newreq.pem /etc/mail/certs/key.pem
cp newcert.pem /etc/mail/certs/cert.pem
chmod 400 /etc/mail/certs/key.pem When the command ‘CA.pl -newca’ asks for a Common Name, fill in the name of
your organization. When the command ‘CA.pl -newreq-nodes’ asks for a Common
Name, you must enter the hostname of your smtp server and it must be the
same name as your smtp-server field on the mailclient, e.g. smtp.domain.nl. 8. Restart sendmail : kill `head -1 /var/run/sendmail.pid`
/usr/sbin/sendmail -L sm-mta -bd -q30m
telnet localhost 25 9. Check if sendmail supports STARTTLS. Issue a ‘EHLO localhost’ command.
You should see a line 250-STARTTLS: root@server:/# telnet localhost 25
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
220 server.pc184.nl ESMTP Sendmail 8.12.7/8.12.7; Wed, 19 Feb 2003
10:59:57 +0100
EHLO localhost
250-server.pc184.nl Hello root@localhost [127.0.0.1], pleased to meet
you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-STARTTLS
250-DELIVERBY
250 HELP Check your logfiles if you don’t see it (increase LogLevel to 14 in your
sendmail.cf). So far for the server side setup.
STEP 2: Client side setup: The next step is to configure your mailclients for SSL smtp connection and
install the client personal and root certificates on them. If you don’t
install these certificates, the client will complain that it cannot verify
the server certificate. This is normal, because you are using a self signed
servercertificate. You do not have this problem if you are buying a
certificate from a trusted provider. For Outlook Express 6 e.g., you wil see this warning: “The server you are connected to is using a security certificate that could
not be verified. A certificate chain processed, but terminated in a root
certificate which is not trusted by the trust provider.” This is how you create your client certificate: cd /usr/local/ssl/certs
../misc/CA.pl -pkcs12 It will create a file newcert.p12 that you can import in your client. You
will have to fill in a password, that the client have to use when he imports
the newcert.p12 file, so don’t use the same as you have used earlier. — For Outlook Express 6 you can follow these steps: 1. Copy the file newcert.p12 to a directory on your Windows client and
rightclick on it. 2. Choose install PFX and follow instructions. It will install a personal
and a root certificate. That’s great. You can check it in Explorer >
Internet Options. 3. In Outlook, turn on the SSL option for your outgoing mailserver. — For Netscape Messenger 4.7 you can follow these steps: 1. Start Messenger, click on the little lock on the bottom left corner. 2. Choose Certificates > Yours > Import a certificate 3. Import the file newcert.p12. 4. Click on Signers, select your CAcert, and edit it to enable all features. 5. Click on Yours, select your personal cert, and click Verify. You
should get “successfuly verified”. 6. Enable Secure SMTP in Messenger config. Now send a mail to yourself and check the message source. It must contain a
Received header with SSL information. You can also check your sendmail log.
If you see Verify=OK, then the server verified the presented client
certificate as OK. If you see Verify=NO, then the client didn’t present a
certificate and you are probably using Outlook Express. This is what I found
on the Internet: Outlook Express as of Internet Explorer 5 will work, but it
will not present any client certificate. So you can encrypt your email
transfer but you cannot authenticate (and relay) with client certificates
(source:
http://www.aet.tu-cottbus.de/personen/j … /test.html). Post
a follow-up for comments on this. I get Verify=OK with Netscape Messenger 4.7 and Verify=NO with Outlook
Express 6.
STEP 3: Allow relaying based on client certificate: The last step is to allow relaying based on a trusted client certificate.
This is very useful, because your client can then send mail to you
mailserver, independent of his IP. It only works if the server can verify
the client (Verify must be OK). Do the following: 1. Open your sendmail logfile and search for the “cert-issuer” field that
came from your client. 2. Copy the content of this field to your access database file (probably
/etc/mail/access_map, see also http://www.sendmail.org/m4/anti_spam.html)
and insert CERTISSUER: and RELAY, like this:
CERTISSUER:/C=NL/ST=SomeState/L=SomePlace/O=SomeOrg/CN=SomeOrg/emailAddress=
SomeEmail RELAY 3. Create database map: makemap hash access_map because you want to relay. You can use [email protected]. It will bounce your
mail and you can check all headers. Remember that this does this setup only
provide a secure transmission from sender to mailserver. Your mail will
probably go unsecure from there. Now, that’s it. I hope this document is usefull and correct, don’t mail me
for suggestion/corrections but please follow-up to this post. You can find more information on: http://www.sendmail.org
http://www.openssl.org
http://www.sendmail.org/~ca/email/starttls.html
http://www.linuxjournal.com/article.php?sid=4823
http://www.ofb.net/~jheiss/sendmail/tlsandrelay.shtml]]>

Setup SSL for Solaris LDAP client (certutil and openssl)

http://blogs.sun.com/roller/page/baban? … _ssl_using

Directory server side


The following shows how to setup Sun Directory Server 5.2 and Solaris LDAP
client for SSL. I have tried to give openssl, certutil, PEM, DER examples (and
Directory server console at some places) to achieve the same result.

Assumptions


myhost.test.sun.com == fully qualified hostname of the Directory server. /var/mps/serverroot == serverroot for the Directory server. dc=sun,dc=com == Directory server already setup with this suffix # openssl is delivered in /usr/sfw/bin on Solaris 10 # Please refer to appropriate manpages for description of various command-line
options used below.

DER and PEM


DER: a binary format PEM: base-64 encoded DER format with header and footer certutil: Default is DER. For PEM, use -a openssl: Default is PEM. For DER, use -inform DER and/or -outform DER

Create Test CA


1. openssl # The /usr/sfw/bin/CA.pl script will create a directory structure either under
the current working directory or under /etc/sfw/openssl depending upon the
version of openssl you are using. I suggest checking the value of CATOP
variable in /usr/sfw/bin/CA.pl. If you want to create CA under /CA/cacertdb : mkdir -p /CA/cacertdb; cd /CA/cacertdb Modify CATOP in /usr/sfw/bin/CA.pl to /CA/cacertdb Modify dir under [ CA_default ] in /etc/sfw/openssl/openssl.cnf to
/CA/cacertdb perl /usr/sfw/bin/CA.pl -newca # Default name for CA cert is cacert.pem 2. certutil # Create CA certificate DB mkdir -p /CA/cacertdb certutil -N -d /CA/cacertdb -P ca- # Create a self-signed CA certificate certutil -S -x -n ca-cert -s cn=CA Certificate certutil,ou=TEST,o=Sun
Microsystems Inc.,l=Menlo Park,st=CA,c=US -t CTPu -v 120 -d /CA/cacertdb -P
ca- -5 # when prompted, select (5) SSL CA and ‘y’ for critical extensions # Export the CA cert into an output file in PEM format certutil -L -d /CA/cacertdb -P ca- -n ca-cert -a > cacert.pem

Create NSS DB for Directory server


1. Console Use the Directory server console => Manage Certificates. The DB is created when
trying to use any of the certificate functions for the first time. With the new
DS6.0 directory server, the NSS DB will be created when creating the server
instance so this step won’t be necessary 2. certutil certutil -N -d /var/mps/serverroot/alias -P slapd-myhost- # Remember the password you have given

Generate Certificate Signing Request (CSR) for server cert


1. Console Use the Directory server console => Manage Certificates to generate CSR and save
it to a file 2. certutil certutil -R -s cn=myhost.test.sun.com,ou=TEST,o=Sun Microsystems
Inc.,l=Menlo Park,st=CA,c=US -o DER.csr -d /var/mps/serverroot/alias -P
slapd-myhost- 3. openssl # Generate 2048-bit RSA private key openssl genrsa -out privkey.pem 2048 # OR Generate 2048-bit DSA private key openssl dsaparam -out DSAparam.pem 2048 openssl gendsa -out privkey.pem DSAparam.pem # Generate the certificate request openssl req -new -key privkey.pem -out PEM.csr # Display the content and public key from the certificate request openssl req -in PEM.csr -text -pubkey

Sign CSR using Test CA


1. certutil # Sign DER CSR certutil -C -c ca-cert -i DER.csr -o ./cert.der -v 12 -d /CA/cacertdb -P
ca- -5 # Sign PEM CSR certutil -C -c ca-cert -a -i PEM.csr -o ./cert.pem -v 12 -d /CA/cacertdb -P
ca- -5 2. openssl openssl ca -policy policy_anything -cert cacert.pem -in PEM.csr -out
./cert.pem

Import signed certs into NSS DB


1. Console Use Manage Certificates tab to import pem certificates 2. certutil # Import PEM server cert certutil -A -a -n server-cert -i ./cert.pem -t Pu -d
/var/mps/serverroot/alias -P slapd-myhost- # Import DER server cert certutil -A -n server-cert -i ./cert.der -t Pu -d /var/mps/serverroot/alias
-P slapd-myhost- # Import PEM CA cert certutil -A -a -n ca-cert -i cacert.pem -t CT -d /var/mps/serverroot/alias
-P slapd-myhost- # List the contents certutil -L -d /var/mps/serverroot/alias -P slapd-myhost- # List the contents of a specific cert certutil -L -d /var/mps/serverroot/alias -P slapd-myhost- -n server-cert 3. openssl # Import openssl certificates/keys into NSS DB. Convert cert, key and CA cert
into pkcs12 format openssl pkcs12 -export -in cert.pem -inkey privkey.pem -certfile cacert.pem
-name MY CERTIFICATE -out mycert.p12 # Import it into NSS DB pk12util -i mycert.p12 -d /var/mps/serverroot/alias -P slapd-myhost- -v

Enable SSL


1. Console. # From Configuration tab, select Encryption. # Select Enable SSL for this server # Select Use this cipher family # Select Certificate # Select Do not allow client authentication OR Allow client authentication
but NOT Require client authentication # Save and Restart the directory server from command line. You will be prompted
for Enter PIN for Internal (Software) Token # For automatic startup of SSL, add NSS DB password to the following file cd /var/mps/serverroot/alias vi slapd-myhost-pin.txt Internal (Software) Token:your-NSSDB-password-here chmod 400 slapd-myhost-pin.txt directoryserver stop directoryserver start

Run idsconfig


/usr/lib/ldap/idsconfig # Assume: Naming Base DN: dc=test,dc=sun,dc=com Domain: test.sun.com
# When prompted for Authentication Methods, choose atleast one that starts with
tls: # Choose appropriate name for the profile (say tls-profile). The default name is
default.

Solaris Native LDAP client side


# Create NSS DB (Don’t enter password. Just hit return) certutil -N -d /var/ldap chmod 444 /var/ldap/* # Download the Test CA certificate on the client machine into a temporary
location. Ex: /var/tmp/cacert.pem # Add CA certificate to the NSS DB certutil -A -n ca-cert -i /var/tmp/cacert.pem -a -t CT -d /var/ldap # Verify that myhost is fully qualified. Else modify /etc/hosts (and if
necessary /etc/nssswitch.conf) getent hosts 11.22.33.44 11.22.33.44 myhost.test.sun.com # Test with ldapsearch ldapsearch -v -h myhost.test.sun.com -p 636 -Z -P /var/ldap/cert8.db -b
dc=sun,dc=com -s base objectclass=* # Initialize Native LDAP client using profile tls-profile. /usr/sbin/ldapclient init -a profileName=tls-profile -a
domainname=test.sun.com -a
proxyDN=cn=proxyagent,ou=profile,dc=test,dc=sun,dc=com -a proxyPassword=proxy
11.22.33.44]]>

How to convert Redhat Enterprise Linux to CentOS and use yum

Why do you want to do this?

Well, this is for those who don’t need support, but happen to have the install cds for RHEL and do need updates.

Centos pretty much is the same as Redhat except that they are compiled on different machines and possible are compiled with different compilers. You can get more information at http://www.centos.org.

I think the way the versioning works is like this:

Redhat 3 update 7: CentOS 3.7

Redhat 4 update 2: CentOS 4.2

Redhat 4 update 3: CentOS 4.3

You get the drift.

Here’s the list of RPMs you’ll need. I just run wget for each of them.

wget http://mirror.stanford.edu/yum/pub/cent … noarch.rpm

wget http://mirror.stanford.edu/yum/pub/cent … 4.i386.rpm

wget http://mirror.stanford.edu/yum/pub/cent … 1.i386.rpm

wget http://mirror.stanford.edu/yum/pub/cent … noarch.rpm

wget http://mirror.stanford.edu/yum/pub/cent … noarch.rpm

wget http://mirror.stanford.edu/yum/pub/cent … 2.i386.rpm

wget http://mirror.stanford.edu/yum/pub/cent … 1.i386.rpm

After grabbing them all, I just install all of them:

Make sure you don’t have other rpms in the directory and run:

rpm –force -ivh *.rpm

Reason for the force is because it conflicts with redhat-release-4ES-5.4. I don’t care too much about that.

Now, you’re on CentOS. To upgrade packages now, just run:

yum update

Another thing that’s cool about this is that you don’t have to bother resolving dependencies cause YUM does it for you. To install a package for example, gcc, just run:

yum install gcc

up2date does the same, but you’ll need Redhat’s subscription.

City View Restaurant – San Francisco – bad

662 Commercial Street
San Francisco, CA 94111
(415) 398-2838 “Sorry guys, I can only give it 1 star and that’s being generous because I’m giving it the star based on cleanliness. It’s clean compared to most Chinese restaurants. The dim sum is between mediocre to poor and Chinatown being so close by, I’d much rather walk to Chinatown and pick some up there and get similar quality and pay half the price. Koi Palace I still find is the best – I occasionally get bad food there, but it’s still the best on average. Here’s my analysis:
– cleanliness +1
– no hostess at the door – I didn’t even know what to do – just walk in and see a small barrier in front – should I seat myself? wasn’t sure -1
– waiter asked if I wanted tea – didn’t bother to ask what kind of tea … just tea … and brought a couple of cups and a pot. -1
– they all tried to speak English – this is good with non-Chinese speaking folks, but they didn’t understand me in English! I asked for vinegar 3x! So I asked in Chinese. -1
– shu mai – okay. was good compared to everything else. +1
– some good uncommon dishes – mostly fried, but they were good +1
– sand in my scallop gow (pretty common as it’s hard to clean, but the scallop seemed to have been processed – didn’t have the chewy texture -1
– ha gow – bad texture – soft and now chewy -1
– near the end of closing, a guy walked up and mumbled – I didn’t know what he said (it was something in Chinese), so I just shook my head and he took the check and calculated it -1 My girlfried said this place was almost like Koi Palace. Sorry… food quality is not even close. Price is a bit high too – I think it may be around the same. This place wouldn’t be my choice – ever.”]]>

How to Set Up DNS Blacklisting in a Lab Environment for Test

This is a very simple setup for those who have a lab environment where they do not want to be connected to the public Internet while doing the testing.

Some background:

The way dnsbl works is that when a connection is made to your mail server, it will take the client’s IP address, reverse it, append a domain onto it, and do a dns A or TXT record lookup for that name.

For example, if a spammer’s IP is 10.4.17.108, and you are using spam.list.com as your dnsbl site, your MTA will do a query for 108.17.4.10.spam.list.com. If the query returns positive, it means that the IP address is listed in the blackhole list and that mail should be rejected.

So the first thing you will need to do is set up a simple dns server. You can find out how to do that by consulting the DNS & Bind book or http://docs.sun.com/db/doc/816-7511 or various other sources.

Then, you need to set up a zone. Here's a sample:
 
# cat /var/named/spam.list.com
 
$TTL 86400 
@ 1D IN SOA @ root (
  42 ; serial
 3H ; refresh
 15M ; retry
 1W ; expiry
 1D ) ; minimum
NS localhost.
 A 10.4.16.11
108.17.4.10 IN A 127.0.0.2
108.17.4.10 IN TXT "10.4.17.108 is listed in spam.list.com"

With this in tact, all you need to do is set up your MTA to use spam.list.com for dnsbl calls.

ESX3 – remote console not coming thru – everything else ok

Problem: From the Virtual Infrastructure Client, I log in and can do whatever I want except see a VM’s console. The VM can power up, I can modify the VMs, but when I go to the console, it just gives me a black blank screen. When I use open console, I get a timeout. I set up the vmx file so that I could use vnc to connect to the console and it works fine. When using the webAccess, I can see the console just fine too. What gives?

In the VI3 server, connections are handled a little differently. Incoming RC connection go to port 902 in the COS: vmware-authd service Then, the MKS (mouse, keyboard, screen) connection happens on port 903 – vmware-vmkauthd listens on port 903. Since connections to port 903 are forwarded to COSShadow, COS would not see those packets. The client actually makes a request on port 902, but then, the server gives a redirect to the client to connect on port 903. If there’s any type of NAT in between or some other network tweak, it could cause this to fail.

Here’s the workaround:

1) Open up the /etc/vmware/config file and append to the bottom:

vmauthd.server.alwaysProxy = “TRUE”

2) Restart the management agents by running:

/etc/init.d/mgmt-vmware restart

3) Disconnect and reconnect the Virtual Infrastructure Client or VirtualCenter from the ESX server.

This will avoid the authd redirection and it should allow your remote console to function properly.

How to allow ssh into a machine w/o a password

First thing you need to do is give your public key to the server that you’ll be allowed into:

To generate the keys I run (on the client):

ssh-keygen -t dsa

Here’s the output:

Generating public/private dsa key pair.

Enter file in which to save the key (/home/alton/.ssh/id_dsa):

Created directory ‘/home/alton/.ssh’.

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/alton/.ssh/id_dsa.

Your public key has been saved in /home/alton/.ssh/id_dsa.pub.

The key fingerprint is:

9b:e8:24:89:34:78:ab:fd:85:93:97:df:10:9c:c8:16 alton@streetfighter

Now you’ve got to move your public key to the other machine (the server). I just take a look at the contents of the file:

[alton@streetfighter ~]$ cat /home/alton/.ssh/id_dsa.pub

ssh-dss AAAAB3NzaC1kc3MAAACBASC1tnxqkSqdGswZkp1P0o6Xn93N9XB5VpenK4k/bV2g7ojywh83CAhjhM5gKlCJ2XI+gM+XD12t+M3+Gxlre79ltiH+L86A33trW6PmUR9cQOp9cLHEzC5bjfs3esqWuuFxC4ObpHbJXakNmSQlSsNzE8ZnGG6emHJUVkNyTcjXAAAAFQD1+ZD6LG2PlwPRHLYmVxGWOm3woQAAAIAHR88SB2dnnjE2a9fQAydR2pbMOrh4X7CISuCnGtPp0lFwAIm5WAMS2oQ8Mh9HG8ou9wjhPgGSlCe4jvZEZyqlOADTZLX8hzno8LMHMTBbNxKji3qGOzJZJBbdhwg9GwitWbrHrXfZS7p2+HAIvDKINleapgrXwrInEJ6zWPYDewAAAIAo4Nud2c06/3A9LqIGeB64Nvecb2MOBOaBSeiXHqOSE/c1a9gmTCb5im3qIcrWs+cgUXbCxyHWaYQYTWUWsLh79TaLIe/rXOMr58aXQ34k1rcXaOgw3nb45YxcEIbAcqO85zc+clpfhTVzM8Aqkh5hv1b9/1pBkz75oC5KsYYkrPQ== alton@streetfighter

Then I go to the other machine and copy the contents into ~/ssh/authorizedkeys

So in the file, I add a new line if it exists and:

ssh-dss AAAAB3NzaC1kc3MAAACBASC1tnxqkSqdGswZkp1P0o6Xn93N9XB5VpenK4k/bV2g7ojywh83CAhjhM5gKlCJ2XI+gM+XD12t+M3+Gxlre79ltiH+L86A33trW6PmUR9cQOp9cLHEzC5bjfs3esqWuuFxC4ObpHbJXakNmSQlSsNzE8ZnGG6emHJUVkNyTcjXAAAAFQD1+ZD6LG2PlwPRHLYmVxGWOm3woQAAAIAHR88SB2dnnjE2a9fQAydR2pbMOrh4X7CISuCnGtPp0lFwAIm5WAMS2oQ8Mh9HG8ou9wjhPgGSlCe4jvZEZyqlOADTZLX8hzno8LMHMTBbNxKji3qGOzJZJBbdhwg9GwitWbrHrXfZS7p2+HAIvDKINleapgrXwrInEJ6zWPYDewAAAIAo4Nud2c06/3A9LqIGeB64Nvecb2MOBOaBSeiXHqOSE/c1a9gmTCb5im3qIcrWs+cgUXbCxyHWaYQYTWUWsLh79TaLIe/rXOMr58aXQ34k1rcXaOgw3nb45YxcEIbAcqO85zc+clpfhTVzM8Aqkh5hv1b9/1pBkz75oC5KsYYkrPQ== alton@streetfighter

That’s all.

license problem…not enough licenses, but 0 of 6 are used

LMtools seems to check out the licenses according to their logs, but they check back in immediately. Interesting huh? We tried changing the file different ways – it was so weird. Finally, we had someone in support use the license checker tool that they have and they found that we mixed up the hosted licenses w/ the server based licenses – doh! … so we just separated them and created new files and it was all set.

It turns out that the website when generating licenses can generate host based licenses instead of server based licenses. You can tell the difference by seeing:

VENDOR_STRING=licenseType=Host

opposed to:

VENDOR_STRING=licenseType=Server