SSL and Certificates
The Most Common OpenSSL Commands
http://www.sslshopper.com/article-most-common-openssl-commands.html
Continues to be a great resources for keytool. Another similar resource exists for OpenSSL.
Southern Illinois University - File Encryption Guidelines and Procedures
http://pki.siu.edu/encrypting_files.html
Web Help Desk Documentation Library | Installation | Importing an SSL Certificate
http://docs.webhelpdesk.com/m/5197/l/54068-importing-an-ssl-certificate
A CA Reply is the signed certificate, the result of a CA signing a certificate request (CSR).
Certificate chains may be of any length. The highest certificate in the chain, the root certificate, should be a self-signed certificate, signed by the trusted CA. Each certificate in the chain must imported into the keystore so that the complete chain can be sent to the browser. If the CA Reply does not include the chain certificates, they must be added to the keystore manually before the CA reply. The certificates must be imported in order of dependency—i.e., the root certificate must be added first, then the next chained certificate that was signed by the root certificate, and so on, down to the CA reply.
Michael Vorburger's Old Blog: Setting up two-way (mutual) SSL with Tomcat on Java5 is easy!
http://blog1.vorburger.ch/2006/08/setting-up-two-way-mutual-ssl-with.html
A pretty comprehensive tutorial on setting up 2-way SSL with Tomcat, including how to set up the keystores using keytool.
Bash
Bash Regular Expressions | Linux Journal
http://www.linuxjournal.com/content/bash-regular-expressions
Using regular expressions in bash and how to extract the match data values.
#!/bin.bash
if [[ $# -lt 2 ]]; then
echo "Usage: $0 PATTERN STRINGS..."
exit 1
fi
regex=$1
shift
echo "regex: $regex"
echo
while [[ $1 ]]
do
if [[ $1 =~ $regex ]]; then
echo "$1 matches"
i=1
n=${#BASH_REMATCH[*]}
while [[ $i -lt $n ]]
do
echo " capture[$i]: ${BASH_REMATCH[$i]}"
let i++
done
else
echo "$1 does not match"
fi
shift
done
Advanced Bash-Scripting Guide: Chapter 8.
http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-8.html
Bash functions don't explicitly declare their variables. You just access $1, $2, $3, ... to access a function's parameters.
#!/bin/bash
function quit {
exit
}
function e {
echo $1
}
e Hello
e World
quit
echo foo
linux - Extract File Basename Without Path and Extension in Bash - Stack Overflow
http://stackoverflow.com/questions/2664740/extract-file-basename-without-path-and-extension-in-bash
Bash string manipulations can make easy work of parsing file names. Pretty cool!
$ s=/the/path/foo.txt
$ echo ${s##*/}
foo.txt
$ s=${s##*/}
$ echo ${s%.txt}
foo
$ echo ${s%.*}
foo
bash String Manipulations Issue 18
http://linuxgazette.net/18/bash.html
More information on bash string manipulations.
Given:
foo=/tmp/my.dir/filename.tar.gz
We can use these expressions:
path = ${foo%/*}
To get: /tmp/my.dir (like dirname)
file = ${foo##*/}
To get: filename.tar.gz (like basename)
base = ${file%%.*}
To get: filename
ext = ${file#*.}
To get: tar.gz
Advanced Bash-Scripting Guide: Chapter 7. Tests
http://tldp.org/LDP/abs/html/nestedifthen.html
Nested if/then condition tests.
a=3
if [ "$a" -gt 0 ]
then
if [ "$a" -lt 5 ]
then
echo "The value of \"a\" lies somewhere between 0 and 5."
fi
fi
# Same result as:
if [ "$a" -gt 0 ] && [ "$a" -lt 5 ]
then
echo "The value of \"a\" lies somewhere between 0 and 5."
fi
Advanced Bash-Scripting Guide: Chapter 6. Tests
http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-6.html
Conditionals with variables.
#!/bin/bash
T1="foo"
T2="bar"
if [ "$T1" = "$T2" ]; then
echo expression evaluated as true
else
echo expression evaluated as false
fi
Advanced Bash-Scripting Guide: Chapter 7. Other Comparison Operators
http://www.tldp.org/LDP/abs/html/comparison-ops.html
Integer comparisons is a little different from string comparison.
-eq
is equal to
if [ "$a" -eq "$b" ]
-ne
is not equal to
if [ "$a" -ne "$b" ]
-gt
is greater than
if [ "$a" -gt "$b" ]
-ge
is greater than or equal to
if [ "$a" -ge "$b" ]
Why can't a trusted public key with certificate chain be imported into my truststore and still retain it's chain?
open https://www.java.net//node/674524
https://www.java.net//node/674524
Apparently, in order to create a public key with a certificate chain that is recognized in one's truststore, they must be associated with a private key. Since any given keystore should only have one private key, and since it is not good form to carry around someone else's private key, it seems logical that the trusted certificate entries in one's truststore (or the trusted cert entries in one's keystore) not contain trusted cert entries with full keychains.
Yeah, it is a bit unintuitive, but you cannot import certificate chains *unless* they are associated with a private key (as in the CA's reply to the CSR). Check the docs on how to import to an existing key entry (need to specify its alias).
Ivaylo
PS
There are two types of entries- key entries and trusted cert entries, and only the key entry can contain a "chain" of certificates, attached to it. The trusted cert entries are all single cert entries.
Import PKCS7 (Chained Certificate) using KeyTool command to JKS - Stack Overflow
http://stackoverflow.com/questions/15814569/import-pkcs7-chained-certificate-using-keytool-command-to-jks
keytool import or importcert can take a text file with PEM blocks or a PKCS7 file as an input file.
openssl pkcs7 -in initial_file.p7b -inform DER -print_certs -outform PEM -out certs_chain.pem
Security
More great information on message-level encryption. While the whole document is relevant only to the Web Services Stack product, there are some useful points that we can pull from the beginning of the document.
- Message-level security is applied between the web service client and the web service itself in both directions.
- Message-level security secures the message content itself, but it does not secure the communication channel. This is in contrast to transport-level security, where the communication channel is secured.
- "useReqSigCert" is a special fictional encryption user that is recognized by the security module. In this case, your certificate (that is used to verify your signature) is used for the encryption of the response. Thus, it is possible to have only one configured encryption user for all clients that access the service.
- Message-level security allows you to digitally sign or encrypt documents exchanged between systems or business partners. It improves communication-level security by adding security features that are particularly important for inter-enterprise communication. Message-level security is recommended and sometimes a prerequisite for inter-enterprise communication.
- A digital signature authenticates the business partner signing the message and ensures data integrity of the business document carried by a message.
- Signatures are used in two scenarios:
- Non-repudiation of origin
- The sender signs a message so that the receiver can prove that the sender actually sent the message.
- Non-repudiation of receipt
- The receiver signs a receipt message back to the sender so that the original sender can prove that the receiver actually received the original message.
- Message-level encryption is required if message content needs to be confidential not only on the communication lines but also in intermediate message stores.
Message-level security relies on public and private x.509 certificates maintained in the J2EE keystore, where each certificate is identified by its alias name and the keystore view where it is stored. Certificates are used in the following situations:
- When signing a message, the sender signs it with its private key and attaches its certificate containing the public key to the message.
- The receiver then verifies the digital signature of the message with the sender’s certificate attached to the message. There are two alternative trust models to verify the authenticity of the sender’s public certificate:
- In the direct trust model, the signer’s public key certificate is compared with the locally maintained, expected public key certificate of the partner. Therefore, the direct trust model requires offline exchange of public key certificates, which can be self-signed or issued by a CA..
- In the hierarchical trust model, the signer’s public key certificate is validated by a locally maintained public certificate of the CA that issued the signer’s public certificate. In addition, the subject name and the issuer of the signer’s certificate is compared with the expected partner’s identity configured in a receiver agreement on the receiver side.
- Generally, the hierarchical trust model enables chains of certificates attached to the message. The certificate used for signing has to be signed by a root CA.
- In the hierarchical trust model, the sender and the receiver only need to agree upon the CA and the subject name that the sender has used in its certificate.
- When encrypting a message, the sender encrypts with the public key of the receiver (also verifying the correctness of the receiver’s certificate by using the public key of the certificate’s root CA).
- The receiver decrypts with its private key certificate.
A practical description of essential PKI concepts is provided in " What is PKI?" by Entrust. Here is a summary of some concepts:
- Public & Private Keys – Public and private keys are complementary: public keys are used for encryption, and private keys are used for message decryption. The public key goes through a provisioning process and is provided to the "public" as an X.509 certificate. An X.509 certificate carries with it detailed information about the certificate owner (for example, name and e-mail address) and additional information about the certificate authority (CA) used to vouch for the validity and integrity of the public key contained in the X.509 certificate. The private key never leaves the enterprise and is the "crown jewel" of the security infrastructure.
- Trusting an X.509 certificate – Whenever an X.509 certificate is presented, the receiver has to establish that the X.509 is trusted. This trust is established by certificate chain traversal, a mechanism where the X.509 receiver verifies that the issuing authority (certificate authority) indeed issued the X.509 certificate presented. An additional check required by the receiver is to check whether the X.509 certificate has been revoked. This check is accomplished by looking up the X.509's serial number in a list of revoked certificates stored in a Certificate Revocation List (CRL). You may chose not to use an issuing certificate authority (CA) and use self-signed certificates. Such certificates have to be registered with the receiver as trusted certificates that do not require certificate chain validation.
- JKS – Java Key Store is a portable repository of X.509 certificates and private keys; it is used by Java-based applications for cryptographic operations.
Message-level security is the cornerstone of enterprise-class SOA. Using SOAP encryption and SOAP signatures, confidentiality and integrity remain "always on" by being independent of transport protocols. With security now living within the SOAP messages, it does not matter if the transport pipe – HTTP, FTP, JMS – between Web service consumers, producers, or intermediaries is SSL enabled.
Message-level security provisions have the following additional advantages when compared with transport-level security alone:
- Granular Security – message-level encryption on any selected part of the SOAP message.
- Always on Security – SSL security features last as long as the SSL session is established. With message-level security, SOAP messages at rest can be encrypted even after the SSL connections are terminated. Security now lives within the message and is independent of the transport.
Vim
reformat in vim for a nice column layout - Stack Overflow
http://stackoverflow.com/questions/1229900/reformat-in-vim-for-a-nice-column-layout
The 'column' command is actually a Bash command that we are pulling into the current document in our vim session.
:%!column -t -s ','
Ruby
Ruby Java Bridge
Apparently provides an API for Ruby to execute java code.
