Sometimes e-mails are stored as a plain text file. This might be due to backup solutions or as in my case, sometimes I have to save e-mails in text format because the client has issues with more complicated S/MIME mails with attachments.
In such cases the text file itself contains the multipart message body of the e-mail, so the attachments are provided as base64 streams:
These data can be extracted manually, but that’s a wearisome task. It’s easier to use munpack, which can easily extract attachment(s) out of such text files and write them into a proper named files.
$ munpack -f mail.txt
Within the Linux eco system certificates are often exchanged in PEM format. However, when you have to deal with other, most often proprietary eco systems you must be able to export the certificates in other file formats. For example, if you have certificates stored as PEM files and need to export them in DER format which often ends in
.der you can use openssl to rewrite them:
$ openssl x509 -outform der -in MyCertificate.pem -out MyCertificate.crt
When you set up the TLS encryption of a web or also of an IMAP server like Dovecot it is sometimes handy to test the encryption on command line level, to see what really happens there. A good tool to do just that is
# openssl s_client -crlf -connect www.example.net:993
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready.
Afterwards, if you want to for example try an IMAP login, the command is as follows:
A login user password
A OK User logged in
A OK [CAPABILITY IMAP4rev1 ...
A status INBOX (messages)
* STATUS INBOX (MESSAGES 0)
A OK Status completed.
* BYE Logging out
C OK Logout completed.
At the same time, if you want to test HTTPS encryption:
$ openssl s_client -crlf -connect www.example.net:443
GET / HTTP/1.0
HTTP/1.1 302 Found
When you try to connect to a web server which has a certificate signed by an unknown root ca, you can compare the TLS/SSL fingerprint of the server with the one of the certificate. For example, if you use your Android phone to securely connect to your own server the phone might not have the root ca of your TLS certificate and thus presents you the fingerprint for you to verify.
Thus, beforehand you have to calculate the TLS fingerprint of the server certificate. This can be done with a single command:
# openssl x509 -noout -fingerprint -in /etc/pki/tls/certs/www.myserver.de.public-cert.ssl.crt
If you regularly shh to a specific server, it is handy to copy the public part of your ssh key to the other server to avoid putting in the login password all the time. But instead of manually picking your public key, invoking scp manually to throw it to the server and calling echo/cat to attach it to
you can use one handy little command:
# ssh-copy-id email@example.com
Now try logging into the machine, with "ssh 'firstname.lastname@example.org'", and check in:
to make sure we haven't added extra keys that you weren't expecting.
If you need to use a different port the command is a bit different than you might expect:
# ssh-copy-id "email@example.com -p 1234"