Quick procedure for adding a signed certificate to the Oracle Wallet used by the HTTP Server in an Oracle Application Server 10g without using the Oracle Wallet Manager GUI (owm), using the orapki utility:
1. Create Oracle Wallet with auto login:
orapki wallet create -wallet <wallet_name> -auto_login
Where <wallet_name> is specified in the SSLWALLET directive in the configuration file of the HTTP server, usually ORACLE_HOME/Apache/Apache/ssl.conf or OH/ohs/ohs/ssl.conf
2. Add certificate request to the wallet:
orapki wallet add -wallet <wallet_name> -dn 'CN=<server_name>,C=US' -keysize 2048
Replace <server_name> with the server name you need the certificate for, i.e. www.domain.com
3. Export certificate request:
orapki wallet export -wallet <wallet_name> -dn 'CN=<server_name>,C=US' -request req.txt
4. Get your certificate signed by a Certificate Authority (CA):
4.1 For production servers, submit the certificate request (req.txt) to a Commercial CA, you will get back for a cost ($) your signed certificate and trusted certificate(s).
4.2 For test or development servers, a self signed certificate can be used, you can sign your own certificate by using a root wallet:
orapki cert create -wallet rootwa -request req.txt -cert ap_cert.txt -validity 3650
Note that the root wallet needs to exist already and include a root certificate.
5. Add the trusted certificate(s) to new wallet:
orapki wallet add -wallet <wallet_name> -trusted_cert -cert b64cert.txt
You can obtain the b64cert.txt (Base64 encoded root certificate) from the CA who signed the certificate for you.
6. Finally add the signed certificate to new wallet:
orapki wallet add -wallet <wallet_name> -user_cert -cert cert.txt
To verify that your certificate works for the sever name you needed it, access the main web page using the server name:
https://www.domain.com
The browser should not complain about the certificate and you can check the certificate information usually by double clicking the padlock icon in the browser or somewhere in the browser Security options -- depending on the browser and version --.
More information:
May 23, 2012
SSH trusted authentication setup
Simple procedure for setting up private key authentication between two hosts (Linux or Unix). This is one of the necessary steps during the preparation of Oracle RAC nodes, the oracle account must be able to ssh between nodes without providing a password.
1. Generate the private and public key pair in your local machine, your desktop machine or server where you will be connecting to other hosts:
ssh-keygen -t rsa
pass-phrase: xxxxxx
# pass-phrase is optional, press enter for no pass-phrase
That generates two files in the directory ~/.ssh ( where ~ = user's home directory )
id_rsa <- Your private key, don't share
id_rsa.pub <- Your public key
Keep those two files in ~/.ssh
2. Copy your public key id_rsa.pub to the remote system, in the account's home directory you will be using to log into that system:
scp id_rsa.pub remote.host:tempkey
3. Log into the remote host and include your public key in the authorized_keys file:
If the hidden directory .ssh does not exist, create it and set the right permissions first:
ssh remote.host
mkdir .ssh
chmod 700 .ssh
If it was there already, just add the key and set permissions on the file:
cat tempkey >> .ssh/authorized_keys
chmod 700 .ssh/authorized_keys
rm tempkey
That will create the authorized_keys file if it does not exist already and add your key to the list of authorized keys for this account, there could be more than one listed in this file.
4. Exit back to the source server (where your private key is) and try logging into the remote server again, if everything is setup properly, and you did not provide a pass-phrase when creating the keys, you should get the prompt in the remote system without providing the remote account's password, usually there is message about successful private key authentication.
Notes
This functionality is enabled in most servers by default but can be disabled by the system admin in /etc/sshd.conf
These commands assume you are using the same account on both servers (same UID).
Important: Setting up this type of authentication without a pass-phrase is insecure and should only be done between trusted systems, not on systems accessible on the public network.
1. Generate the private and public key pair in your local machine, your desktop machine or server where you will be connecting to other hosts:
ssh-keygen -t rsa
pass-phrase: xxxxxx
# pass-phrase is optional, press enter for no pass-phrase
That generates two files in the directory ~/.ssh ( where ~ = user's home directory )
id_rsa <- Your private key, don't share
id_rsa.pub <- Your public key
Keep those two files in ~/.ssh
2. Copy your public key id_rsa.pub to the remote system, in the account's home directory you will be using to log into that system:
scp id_rsa.pub remote.host:tempkey
3. Log into the remote host and include your public key in the authorized_keys file:
If the hidden directory .ssh does not exist, create it and set the right permissions first:
ssh remote.host
mkdir .ssh
chmod 700 .ssh
If it was there already, just add the key and set permissions on the file:
cat tempkey >> .ssh/authorized_keys
chmod 700 .ssh/authorized_keys
rm tempkey
That will create the authorized_keys file if it does not exist already and add your key to the list of authorized keys for this account, there could be more than one listed in this file.
4. Exit back to the source server (where your private key is) and try logging into the remote server again, if everything is setup properly, and you did not provide a pass-phrase when creating the keys, you should get the prompt in the remote system without providing the remote account's password, usually there is message about successful private key authentication.
Notes
This functionality is enabled in most servers by default but can be disabled by the system admin in /etc/sshd.conf
These commands assume you are using the same account on both servers (same UID).
Important: Setting up this type of authentication without a pass-phrase is insecure and should only be done between trusted systems, not on systems accessible on the public network.
Subscribe to:
Posts (Atom)