I'm trying to get my Zebra ZD410 to print labels from a website. That website is not mine. It runs on https. My printer does work, is connected to my computer, I can send ZPL instructions. The printer is actually connected to my Wi-Fi and has a static IP address of "192.168.2.80".
When browsing to "http://192.168.2.80" the print server page shows up.
The website in question supports, for now, only the Zebra 410 (and most probably other version, just not tested). Their instructions are to click on a link to accept the SSL certificate. Upon clicking on that link, a new page is opened and tries to load https://192.168.2.80, which is refused with "ERR_CONNECTION_REFUSED"
I have tried and successfully sent "!U1 setvar "ip.https.enable" "on" and restarted the printer, it doesn't change anything.
By default, the printer comes with http enabled
Always add a carriage return at the end of your commands in the communication tool
One can enable https by sending ! U1 setvar "ip.https.enable" "on"
The printer comes with no self-signed default certificate for SSL, that's a shame
Anybody can generate self-signed certificates, by opening a terminal and make sure you have openssl installed then type :
openssl genrsa 2048 > HTTPS_KEY.NRD
openssl req -new -x509 -nodes -sha256 -days 365 -key HTTPS_KEY.NRD > HTTPS_CERT.NRD
The certificate file must be named HTTPS_CERT.NRD
The private key file must be named HTTPS_KEY.NRD
Get both files EXACT byte sizes
Files must be manually uploaded in binary mode on the printer on E: (any other method will fail on ZD410, be it driver upload, serial upload, ftp upload, or setup utility upload, because the default destination is not E: but R: and is not RW)
Open Zebra setup utility
Open communication tools
Enter following commands
~DYE:HTTPS_CERT.nrd,B,NRD,REPLACE WITH FILE BYTE SIZE,,-----BEGIN CERTIFICATE-----
REPLACE WITH YOUR CERTIFICATE CONTENT
-----END CERTIFICATE-----
~DYE:HTTPS_KEY.nrd,B,NRD,REPLACE WITH FILE BYTE SIZE,,-----BEGIN PRIVATE KEY-----
REPLACE WITH YOUR KEY CNTENT
-----END PRIVATE KEY-----
^XA
^JUS
^XZ
! U1 setvar "ip.https.enable" "on"
! U1 do "device.reset" ""
Upon restart, one can check if the https webserver was enabled with a command:
! U1 getvar "file.cert"
The printer will answer with all the loaded certificates.
Check the line with HTTPS service. It should have a file and a validity
You can then navigate, on your browser to your printer's ip using https and also send https API triggers.
If you wish to then turn off http, you can disable it by sending this command:
! U1 setvar "ip.http.enable" "off"
Related
I'm trying to get an intermediate certificate using curl, and process the certificate without writing it to a file.
I've figured out how to process a leaf cert and get the distribution point, but that's where I'm stuck.
For an example, let's take stackoverflow (seems pertinent). The first intermediate cert for SO is from http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt.
In an interactive shell, I can do something like this to store the value of the certificate into a variable:
DigiCertIntermediateCert=$(curl http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt)
Then I can check the value of the cert by doing something like this:
echo "$DigiCertIntermediateCert" | openssl x509 -inform DER -outform PEM
This outputs the nice and friendly PEM-formed cert. It looks like this:
-----BEGIN CERTIFICATE-----
MIIEsTCCA5mgAwIBAgIQBOHnpNxc8vNtwCtCuF0VnzANBgkqhkiG9w0BAQsFADBs
...
cPUeybQ=
-----END CERTIFICATE-----
(Note: this will change when the intermediate cert changes, if this isn't exactly the value you're seeing, don't freak out)
Neat! Seems like this should work. Let's throw all this logic into a script with some basic case handling (like if the cert is in a different form, then we should interpret it as that form) and we should be done, right?
#! /bin/bash
cert_content=$(curl -s "$1")
echo "$cert_content"
if echo "$cert_content" | openssl x509 -text -noout; then
echo "Not converting"
echo "$cert_content"
else
echo "Converting"
echo "$cert_content" | openssl x509 -inform DER -outform PEM
fi
What does this output when we feed the url?
...
[binary contents of a certificate]
...
unable to load certificate
4667577964:error:09FFF06C:PEM routines:CRYPTO_internal:no start line:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.230.1/libressl-2.6/crypto/pem/pem_lib.c:683:Expecting: TRUSTED CERTIFICATE
Converting
unable to load certificate
4421875308:error:0DFFF08E:asn1 encoding routines:CRYPTO_internal:not enough data:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.230.1/libressl-2.6/crypto/asn1/a_d2i_fp.c:251:
So it's pretty easy to see that the certificate is in DER form (because of the "Converting" line), but it looks like the certificate is not complete - note the error:
unable to load certificate
4421875308:error:0DFFF08E:asn1 encoding routines:CRYPTO_internal:not enough data:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.230.1/libressl-2.6/crypto/asn1/a_d2i_fp.c:251:
says that there is not enough data.
Why is this different between the script and the actions I'm taking in the shell? How can I feed the binary cert through the openssl tool to get the PEM-form cert out?
As the question alludes, I was not strict enough in my shell usage. The "interactive" session was done using zsh, and the script was run under bash. zsh will append an EOF to variables passed through its pipes, while bash (apparently) does not. Now my quest becomes how to append an EOF to a variable in bash (which, apparently, is non-trivial).
I'm making an app (tiny PHP website) that sends my AirBnB guest info to the police (which I'm required to do - it's what they do in a hotel, when they take your passport at check-in).
The app needs to generate a file with guest's data and then send it to the Czech police department via a digitally signed email. The first part is done but I've got stuck with Mutt for yet another day.
My goal is to send a S/mime signed email with an attachment with a shell script without any user interaction. So something like this:
mutt -s 'My mail ' abc#gmail.com -a report1.txt < report2.txt
The code above sends an email with an attachment but without a digital signature although enabled by default in muttrc.
I've managed to send signed emails with mutt but only via it's interactive shell plus I need to manually type in the password for my private key every time, the code above doesn't ask for the password just sends it without a signature straight away.
I tried generating the key with an empty PEM pass but then OpenSSL didn't like it at all and aborted immediately.
I would use sendmail command instead of mutt.
openssl smime -sign -in report.txt -text -signer cert.pem \
-from you#domain.com -to abc#gmail.com \
-subject "My mail" | sendmail abc#gmail.com
In this example, cert.pem is created from a PKCS12 file:
openssl pkcs12 -in yourcert.p12 -out cert.pem -clcerts -nodes
report.txt is the plain text file/report to be signed and sent.
The OpenSSL smime(1) man page has a few more good examples.
Desperate people do desperate things. I edited the openssl source code to generate Content-Type: text/plain;\r\n instead of Content-Type: text/plain\r\n\r\n so that I could follow up with:
Content-Disposition: attachment;
filename="test.txt"
I am new to SSL/OpenSSL and I'm working on Windows 7. I'm trying to configure HTTPS for my ElasticBeanstalk environment following these instructions.
I'm at Step 2 in "Create a Private Key". After I issue the command to generate the key pair:
openssl genrsa 2048 > privatekey.pem
I get:
Generating RSA private key, 2048 bit long modulus
........................................+++
...............................+++
unable to write 'random state'
e is 65537 (0x10001)
However, it does write a key to my directory. But after the second command:
openssl req -new -key privatekey.pem -out csr.pem
I get:
unable to load Private Key
6312:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: ANY PRIVATE KEY
I've tried Googling this a bit, but none of the solutions I've found seem to be relevant for me. I checked the generated key and it looks like
-----BEGIN RSA PRIVATE KEY-----
{lots of characters}
-----END RSA PRIVATE KEY-----
What am I doing incorrectly?
unable to load Private Key
6312:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: ANY PRIVATE KEY
I ran your commands on OS X, and I could not reproduce the results.
I did use the -config option because I have an "OpenSSL server config template" that makes it easy to generate CSRs and self signed certificates:
$ mkdir test
$ cd test
$ openssl req -new -key privatekey.pem -out csr.pem -config example-com.conf
The configuration file is named example-com.conf, and you can find it at How do I edit a self signed certificate created using openssl xampp?. Edit it to suit your taste (in particular, the DNS names).
If interested, here's the OpenSSL man pages on the req sub-command.
I checked the generated key and it looks like
-----BEGIN RSA PRIVATE KEY----- {lots of characters}
-----END RSA PRIVATE KEY-----
You can validate the key you just created with:
$ openssl rsa -in privatekey.pem -inform PEM -text -noout
Private-Key: (2048 bit)
modulus:
00:b0:91:ce:57:28:0f:5c:3a:c3:29:d7:23:6a:71:
ca:64:49:fc:24:ea:69:a3:09:d6:49:94:17:b9:09:
65:fa:5a:10:47:a4:9b:b8:cd:6d:32:74:19:8d:5c:
79:92:f0:a6:43:9c:75:a3:7b:ef:c4:c3:d9:c2:db:
b9:bd:ec:14:a8:b1:52:73:8f:56:c8:5c:16:08:56:
ff:c2:2b:35:3c:0a:0f:34:d0:91:c1:54:7e:72:e8:
97:bf:ea:46:69:5f:e4:21:8d:7a:f5:a5:6b:6a:e8:
00:56:bc:02:f6:b4:ae:6e:89:a6:50:aa:5b:2f:d8:
7d:99:04:61:51:76:b3:5e:9e:30:52:99:54:26:e2:
3a:54:ec:78:34:e6:9a:b7:c2:58:5c:51:3d:39:52:
d4:6e:0c:6e:a1:a0:a5:f1:4d:5a:f5:0b:1a:6e:dc:
f3:bb:0d:d0:53:51:b0:1a:04:ee:86:35:d5:f3:8b:
0d:bc:19:61:6c:0c:b2:7b:a9:7c:47:97:01:bb:a2:
6a:74:d9:19:e9:df:60:07:d4:95:4c:83:f8:3b:84:
c2:b8:3d:b9:a7:34:0a:9b:a3:c6:70:cc:ef:de:f4:
64:88:f1:56:d3:2a:fd:5a:82:88:96:66:93:6c:a0:
b8:ec:e4:4c:e8:76:5c:9c:fc:c4:60:72:b6:9a:3f:
98:a3
publicExponent: 65537 (0x10001)
privateExponent:
00:87:ab:f1:65:ac:e5:68:93:ca:64:3a:e7:fe:a1:
62:c7:7e:c5:dc:c3:b5:d9:cd:f4:36:e3:30:fb:40:
0a:78:bc:7d:67:df:46:bc:50:34:88:a1:07:05:44:
ba:31:ba:f1:b6:5f:e1:50:76:29:bd:02:54:2f:d2:
cf:bc:ec:4a:cf:78:39:07:8c:6b:3d:56:ec:a3:09:
de:49:9f:13:af:87:77:39:b8:cd:56:45:0b:48:56:
0a:4c:2f:c2:5c:b3:8e:c2:6d:48:be:b9:95:79:36:
bd:13:e8:31:4a:c9:78:82:7d:08:2b:51:4a:f1:cf:
a2:6a:52:20:49:0d:31:34:10:88:02:d7:a7:07:70:
32:b5:f5:8c:cc:d4:b2:8d:b9:aa:bb:33:82:1a:74:
bd:4d:4f:e9:e0:cc:f2:27:fb:98:34:2c:77:56:6f:
88:3a:66:32:5d:7d:57:c6:5b:63:39:fa:32:04:9d:
e3:cc:a5:b6:44:91:fd:7d:d1:b6:2d:16:47:59:81:
3d:cf:d9:a7:58:2a:d6:61:5d:c6:69:3b:7a:70:50:
4f:80:f4:d9:fb:c8:7d:5e:44:9e:ac:c8:e6:aa:49:
c3:d6:df:6b:03:68:25:a3:2b:89:8f:9a:35:3a:58:
7d:71:b4:08:d9:04:7b:b9:96:17:f3:a5:19:c5:07:
4e:c1
prime1:
00:d7:d0:d8:8c:b5:86:ed:0e:06:70:c9:54:00:25:
d7:8c:e4:65:51:1b:c5:ba:33:c2:02:1a:dc:80:a6:
ae:8e:1e:e8:c0:b7:04:11:5a:e3:98:52:8f:4a:7a:
43:b8:e8:1b:c8:d6:d3:b2:dc:70:59:a5:ca:83:bb:
35:f1:6c:f5:cb:d0:f4:04:5e:aa:7c:d0:ec:d7:4a:
d5:1c:7c:e2:67:e4:e8:17:95:9b:4e:2b:a0:26:74:
61:d0:a0:15:27:18:e5:84:b5:54:ef:be:82:35:7e:
78:e0:49:6b:4e:ae:93:53:a0:81:a3:8e:de:d3:e5:
dc:c5:ba:03:36:14:47:97:03
prime2:
00:d1:72:3b:f5:34:b1:11:78:b2:79:f4:3e:d7:be:
bf:cc:b3:09:ea:24:a4:cc:7f:64:73:96:d2:48:9e:
55:bc:79:23:c2:d9:80:81:7d:a4:a5:4b:43:33:8e:
62:04:ec:8d:22:d7:43:5e:41:b6:4d:e9:b0:cc:70:
63:17:70:93:88:81:f5:84:a6:3f:2b:98:33:a3:69:
53:11:c7:95:8c:30:ea:e8:58:c7:77:10:b4:a8:f5:
bf:5e:cf:e1:99:bb:b3:4e:57:d2:4c:f7:73:de:8a:
98:8e:7c:26:37:6c:e4:77:c6:d2:ed:5d:53:a7:15:
c3:9c:67:61:d3:24:9a:f5:e1
exponent1:
00:83:34:59:e2:b9:9d:8c:d2:e1:01:82:b4:89:de:
77:bc:15:42:af:5b:c6:0a:dc:da:8e:f3:0b:a9:3f:
2c:92:04:a2:96:3e:ed:bf:2b:55:80:ce:78:84:db:
ed:fe:25:46:77:04:7b:f1:9a:68:c7:67:ae:c6:05:
73:d7:11:da:21:0e:28:bb:db:5d:a4:c2:53:aa:d3:
b8:da:37:e6:61:29:5e:1c:b0:7c:99:ba:96:03:aa:
ef:a8:a9:1a:13:09:e4:c7:98:82:49:ba:b5:68:96:
3a:20:89:22:2e:d4:9d:86:d2:e6:dd:ab:c7:36:65:
e1:a1:67:e3:f9:e5:bc:5c:47
exponent2:
00:81:6d:b9:55:8f:09:39:05:c0:2d:12:dd:5e:cf:
56:91:35:b6:93:c5:af:3d:5c:20:04:3a:18:9a:9d:
95:d7:d1:78:62:e9:ab:ba:d9:9c:cc:34:95:43:9f:
e2:3c:ae:bd:8c:e1:3f:95:58:c0:42:a7:7e:04:e8:
12:a4:22:82:59:22:0e:49:b9:be:61:bf:3d:71:e7:
1d:59:68:5f:a6:f1:77:c8:bb:4c:0f:ec:f7:e7:4d:
6d:c4:36:6c:70:67:08:a8:0a:27:40:3e:ce:90:a0:
4f:24:05:de:4b:f3:f3:bf:7c:d3:4d:b1:95:87:34:
30:dc:4f:1a:a9:b2:fe:3b:a1
coefficient:
6d:51:b3:6e:87:8d:aa:f0:55:c4:22:21:62:a9:ea:
24:b3:b7:91:40:f5:78:5d:f1:40:45:7e:0d:a2:a3:
54:46:ba:42:33:b6:cd:57:a1:85:bc:3d:ba:1c:eb:
87:33:a9:e9:63:1e:7c:2c:89:98:b9:0f:4b:e8:c4:
79:bd:00:6a:f5:3e:ea:63:f1:9e:aa:47:35:5a:22:
fc:4e:e3:61:7e:eb:dc:a6:c0:2c:d5:fd:22:9f:01:
59:32:15:db:41:99:b7:a8:c1:eb:1e:42:c7:1b:c7:
c8:56:86:a8:34:fe:1c:48:b6:6e:f1:c1:5c:96:bf:
9d:fa:e5:4c:d0:2a:d9:09
unable to write 'random state'
This is a well known problem. OpenSSL uses a default configuration file. You can locate the configuration file with correct location of openssl.cnf file.
The default configuration file includes these lines:
$ cat /usr/local/ssl/macosx-x64/openssl.cnf
...
HOME = .
RANDFILE = $ENV::HOME/.rnd
...
To save the random file, you should point HOME and RANDFILE to a valid location. On Windows, you type set HOME=... and set RANDFILE=... in the command prompt. Or better, change it in the OpenSSL configuration file you use.
Also see How to fix “unable to write 'random state' ” in openssl and How do I make OpenSSL write the RANDFILE on Windows Vista?.
I'm trying to configure HTTPS for my ElasticBeanstalk environment following these instructions.
The instructions are wrong in the image below. Do not place a DNS name in the Common Name (CN).
Placing a DNS name in the Common Name is deprecated by both the IETF (the folks who publish RFCs) and the CA/B Forums (the cartel where browsers and CAs collude). You should pay articular attention to what the CA/B recommends because Browsers and CAs come up with those rules, and the browsers follow them (and they don't follow the RFCs). For reference, see RFC 5280, RFC 6125 and the CA/B Baseline Requirements.
Instead, place DNS names in the Subject Alternate Name (SAN). Both the IETF and CA/B specifies it.
The custom OpenSSL configuration file handles this for you. You just have to change the DNS names listed under the section [ alternate_names ]. For example, here's a set of names set up for the domain example.com. Notice there is no DNS name in the CN:
[ subject ]
...
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Example Company
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
Can you check if you have appropriate permissions when you run both the commands? Maybe try doing the same using a user with Admin Rights.
Also make sure the created file privatekey.pem has appropriate permissions before executing the command below (Use chmod if necessary)
openssl req -new -key privatekey.pem -out csr.pem
Submitting this as answer as I don't have enough reputation to comment.
I believe the root of the problem is the error
unable to write 'random state'
e is 65537 (0x10001)
Searching StackOverflow found these results. I would stress that you run the openssl program as sudo or directly as root to avoid any possible permissions issues.
The fix in Windows:
https://stackoverflow.com/a/12522479/3765769
In Linux:
https://stackoverflow.com/a/94458/3765769
I'm trying to convert a P12 file to a PEM file. When I execute the command, the terminal asks me for three things:
P12 passphrase (I type it in, hit enter)
PEM passphrase (type it in, hit enter)
PEM passphrase confirm (type it in, hit enter)
I know I can execute a sudo command all in one shot by using the following:
echo sudopassword | sudo rm -rf /file.p12;
How can I add all three values in one shot? Thanks
Can you explain what these P12 files are? I found this link which deals with the conversion of pkcs12 Cert/key files to .PEM format using openssl. (http://gridsite.org)
Key to the answer is:
Use -passin file:... and -passout file:... for unattended processing
It's my guess that you will have to specify the -passin file:P12passphrase and -passout file PEMpassphrase options for this case.
This little test confirms how an input passphrase can be specified through a file:<...> parameter. This helps to hide such phrases from any over the shoulder attacks. Don't forget to restrict access to such files. Even though it's a common feature of most openssl commands, it's not explicitly mentioned and it is key to the original question. The full list of options is below.
$ openssl pkcs12 -passin file:P12phrase
Can't open file P12phrase
Error getting passwords
(I leave it to the OP to construct the full command.)
Below are all supported options for the pkcs12 subcommand:
$ openssl pkcs12 help
Usage: pkcs12 [options]
where options are
-export output PKCS12 file
-chain add certificate chain
-inkey file private key if not infile
-certfile f add all certs in f
-CApath arg - PEM format directory of CA's
-CAfile arg - PEM format file of CA's
-name "name" use name as friendly name
-caname "nm" use nm as CA friendly name (can be used more than once).
-in infile input filename
-out outfile output filename
-noout don't output anything, just verify.
-nomacver don't verify MAC.
-nocerts don't output certificates.
-clcerts only output client certificates.
-cacerts only output CA certificates.
-nokeys don't output private keys.
-info give info about PKCS#12 structure.
-des encrypt private keys with DES
-des3 encrypt private keys with triple DES (default)
-aes128, -aes192, -aes256
encrypt PEM output with cbc aes
-nodes don't encrypt private keys
-noiter don't use encryption iteration
-maciter use MAC iteration
-twopass separate MAC, encryption passwords
-descert encrypt PKCS#12 certificates with triple DES (default RC2-40)
-certpbe alg specify certificate PBE algorithm (default RC2-40)
-keypbe alg specify private key PBE algorithm (default 3DES)
-keyex set MS key exchange type
-keysig set MS key signature type
-password p set import/export password source
-passin p input file pass phrase source
-passout p output file pass phrase source
-engine e use engine e, possibly a hardware device.
-rand file:file:...
load the file (or the files in the directory) into
the random number generator
-CSP name Microsoft CSP name
-LMK Add local machine keyset attribute to private key
It's unlikely that these commands are reading from stdin. It's more likely that they're reading directly from the terminal. This allows them to set a mode that doesn't echo the password to the screen. Try echoing your input to /dev/tty.
Beyond that, you'll need to use something like expect / pexect to control these. Those projects were build specifically for this purpose.
Openssl has a -stdin optoin to read its input from stdin. This works:
tmp=`mktemp`
cat > $tmp <<EOF
$1
EOF
cat $tmp | openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key
I've used cat and a here-document to avoid putting the password on the commandline.
I used openssl pkcs12 -in Certificates.p12 -out sampleCore.pem -nodes and it was working for me.
Have you tried just echoing three lines? It would probably work
echo $'P12 passphrase\nPEM passphrase\nPEM passphrase confirm' | cmd
Although I feel I must point out that echoing passwords like this is highly insecure. Not only does the password end up in your bash history file, but it's also visible to anyone else on the system who runs ps.
I am trying to send an email from R, using the sendmailR package. The code below works fine when I run it on my PC, and I recieve the email. However, when I run it with my macbook pro, it fails with the following error:
library(sendmailR)
from <- sprintf("<sendmailR#%s>", Sys.info()[4])
to <- "<myemail#gmail.com>"
subject <- "TEST"
sendmail(from, to, subject, body,
control=list(smtpServer="ASPMX.L.GOOGLE.COM"))
Error in socketConnection(host = server, port = port, blocking = TRUE) :
cannot open the connection
In addition: Warning message:
In socketConnection(host = server, port = port, blocking = TRUE) :
ASPMX.L.GOOGLE.COM:25 cannot be opened
Any ideas as to why this would work on a PC, but not a mac? I turned the firewall off on both machines.
Are you able to send email via the command-line?
So, first of all, fire up a Terminal and then
$ echo “Test 123” | mail -s “Test” user#domain.com
Look into /var/log/mail.log, or better use
$ tail -f /var/log/mail.log
in a different window while you send your email. If you see something like
... setting up TLS connection to smtp.gmail.com[xxx.xx.xxx.xxx]:587
... Trusted TLS connection established to smtp.gmail.com[xxx.xx.xxx.xxx]:587:\
TLSv1 with cipher RC4-MD5 (128/128 bits)
then you succeeded. Otherwise, it means you have to configure you mailing system. I use postfix with Gmail for two years now, and I never had have problem with it. Basically, you need to grab the Equifax certificates, Equifax_Secure_CA.pem from here: http://www.geotrust.com/resources/root-certificates/. (They were using Thawtee certificates before but they changed last year.) Then, assuming you used Gmail,
Create relay_password in /etc/postfix and put a single line like this (with your correct login and password):
smtp.gmail.com login#gmail.com:password
then in a Terminal,
$ sudo postmap /etc/postfix/relay_password
to update Postfix lookup table.
Add the certificates in /etc/postfix/certs, or any folder you like, then
$ sudo c_rehash /etc/postfix/certs/
(i.e., rehash the certificates with Openssl).
Edit /etc/postfix/main.cf so that it includes the following lines (adjust the paths if needed):
relayhost = smtp.gmail.com:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/relay_password
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = may
smtp_tls_CApath = /etc/postfix/certs
smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtp_tls_loglevel = 1
tls_random_source = dev:/dev/urandom
Finally, just reload the Postfix process, with e.g.
$ sudo postfix reload
(a combination of start/stop works too).
You can choose a different port for the SMTP, e.g. 465.
It’s still possible to use SASL without TLS (the above steps are basically the same), but in both case the main problem is that your login informations are available in a plan text file... Also, should you want to use your MobileMe account, just replace the Gmail SMTP server with smtp.me.com.