...
Certificate Manager
Overview
Every secure transaction requires 1) Encryption 2) Authentication 3) Authorization.
- HTTP/S provides the core Encryption whenever used, so all of AAF Components require HTTP/S to the current protocol standards (current is TLS 1.1+ as of Nov 2016)
- HTTP/S requires X.509 certificates at least on the Server at minimum. (in this mode, 1 way, a client Certificate is generated)
- Certificate Manager can generate certificates signed by the AT&T Internal Certificate Authority, which is secure and cost effective if external access are not needed
- These same certificates can be used for identifying the Application during the HTTP/S transaction, making a separate UserID/Password unnecessary for Authentication.
- Authentication - In order to tie generated certificates to a specific Application Identity, AAF Certificate Manager embeds a an Identity Lifecycle Management (ILM) AppID in the Subject. These are created by AT&T specific Internal Certificate Authority, which only generates certificates for AAF Certman. Since AAF Certman validates the Sponsorship of the AppID with requests (automatically), the end user can depend on the AppID embedded in the Subject to be valid without resorting to external calls or passwords.
- ex:
- Authorization - AAF Certman utilizes AAF's Fine-grained authorizations to ensure that only the right entities perform functions, thus ensuring the integrity of the entire Certificate Process
Design and Mechanisms
Use CMAgent for Artifact Management
Preparation
Use Latest CADI latest Code Access Data Identity (CADI) Jar File - Get it from Maven Central ( Open Sourced Version)
Creation
IMPORTANT! if you are using Self-Renewal processes, you MUST include "jks" for Types
...
java -jar /opt/app/cadi/1.3.1/lib/cadi-aaf-1.3.2-full.jar cm_url=https://aaftest.onap.org:8150 create
UserID (dgl@openecomp.org):
...
2016-07-28T09:37:48.455-0500: Call to AAF Certman successful a123@myapp.onap.org, xyz.com
Creating & Deploying Certificates With Certman
- Step 1: Prerequisites
- Step 2: Create Artifacts
- Step 3: Create/Assign Permission
- Step 4: Deploy/Install Certificates
- Step 5: (optional) Give Your Clients a Truststore File
- Special Cases - Templates
Step 1: Prerequisites
The majority of the setup is for establishing the Application's Identity in AAF and ILM. This is required to ensure the chain of responsibility from the Certificates to the Sponsor of the AppID. If your app already uses AAF, that can be skipped. If a AppID is already established for AppID/Password, that one should be used. Do not obtain another one.
- ILM enrolled AppID, because these are about Applications
- AAF Namespace, so we can ensure only the right people may generate a certificate purporting to be that identity
Steps 1 and 2 are accomplished by following these instructions: OnBoarding
- Install CADI (Latest Version) on boxes where you will use "CMAgent"
- Java, should be 1.8+ (1.7 still works)
- Direct Jar Method - this is the best way to use Certificate Manager Agent...
Step 2: Create Artifacts
The App Owner (Should be the Namespace Owner AND the Sponsor of Record of the AppID in ILM Records). Follow these instructions: GUI Instructions
...
- if you want self-renewing certificates, make sure to chose "jks" as an artifact type in step 7
- in step 7, "Directory" must be writable by the user listed in "O/S User". If an application is going to use cadi + certificates, ensure that the process is run by the same user as "O/S User". Information on Unix/Linux file permissions can be found by googling, for instance this post.
- in step 11 ("Copy Artifact"), make sure the list of machines you enter does not contain whitespace
- Alternatively, the GUI can be skipped by following these instructions: Use CMAgent for Artifact Management. In most cases, users should use the GUI instructions above
Step 3: Create/Assign Permission
Use AAF's GUI > Command Prompt to create the following permission and assign it to a role. Pick the GUI for the appropriate environment from Application Authorization Framework
Create Certman Permission
Replace "<ns>" with the name of the application's namespace.
...
perm create com.att.<ns>.certman aaf request
Grant Certman Permission to a Role
For instance if, the deployer is an admin of the app's namespace, grant the permission created above to <ns>.admin. For information on how to create a new role, or to assign a user to a role, see Documentation for Namespace Admins. Replace "<ns>" with the name of the application's namespace. Replace "<some-role" with the name of the deployer's role.
...
> java -jar /opt/app/cadi/1.3.2/lib/cadi-aaf-1.4.0-full.jar place a123@myapp.onap.org mymachine.domain.onap.org
UserID (dgl@openecomp.org): Global Login Password:
2016-07-28T09:47:50.194-0500: X509 validation turned off ...
Reconstitute Private Key 0.114307ms
# NOTE: If you make a mistake in the URL or your Password, run the following:
> java -jar /opt/app/cadi/1.3.2/lib/cadi-aaf-1.3.2-full.jar -logout
and try again.
- " a123@myapp.onap.org " is the AppID reference to the Artifact
- "mymachine.domain.att.com" is the fully qualified Machine Name (FQDN), which matches an Artifiact in Certificate Manager (see above for creation)
- See "Templates" below for Special Cases
- For Automation purposes, CMAgent will try the Java Default for machine if not on Command Line. Whether this returns a fully qualified name (FQDN) may depend on setup. Another option for automation (in Linux) may be replacing "my machine.domain.att.com" with "`uname -n`.domain.att.com"
...
-rw-r--r-- 1 abc123 cssari 736 Nov 9 14:42 org.onap.myapp.crontab.sh
Notes:
- Multiple Types are separated by commas: "type=jks,file,script" to get all of them.
- Great lengths have been taken to ensure that as few special variables are required for Deployment as possible
Self Renewal
Generating the "scripts" are the key to making Certificates Self-Renewing. Always add these scripts for Unix Based Systems. You will have to work your own solution for other O/Ss that don't have "cron".
!! If you use Self Renewal, you MUST have the "jks" files generated!!
Setting up Self-Renewal:
- After deploying certificate above, test the Certificate access with the "check.sh" script
- ALL THE SELF-RENEWAL SCRIPTS ARE "bash" Scripts. If you are not running a bash shell, use "bash" as prefix
- Check the Certificate ID is working
...
· # -- The "msg" file is the result of the check.sh, showing the Check Date and the Expiration Date
- Once the "check.sh" is ensured to work, add the nightly Check to Cron (in Unix).
...
# 3 3 3 3 3 /bin/bash /someone's nightly process
####
bash > bash com.att.myapp.crontab.sh
bash > crontab -l
#### Someone Else's Cron info
...
#### END org.onap.myapp Certificate Check Script #### Other uses:
- Once the Certificates are generated, they may be used for certain accesses to Certificate Manager Agent... but only those functions given to the App
...
Read Artifact 429.56503ms
# Please note that the only those entities given the "Deploy" permission may see the Passwords encrypted within the Property Files
...
REMOTE Show Password 682.36285ms bash> java -jar /opt/app/cadi/1.3.2/lib/cadi-aaf-1.3.2-full.jar cm_url=https://aaftest.onap.org:8150 showpass a123@myapp.onap.org
...
REMOTE Show Password 1443.2354ms
Special Cases - Templates
Note: ILM no longer requires special exceptions for SANs. You may add them in your Artifact at creation time.
...
There are two varieties of templates that are designed to make creating certificates in today's more dynamic environment
Vanity URL:
Many services have Vanity URLs (or Round Robin). AAF is one of these. Normally, Certificate Manager validates whether the deployment call is made from the Artifact created. With the "Vanity URL Template", when deploying a new certificate, the check is made whether the incoming request for deployment is made from on of the machines in the Vanity URL, if so, then it is accepted, and a new Artifact is created for that machine is created in the Template Image for the particular machine requesting.
...
When Deploying, adding the "machine" on the command line is required in the format: <vanity URL>:<real machine name>[:<additional SAN>]*
Domain:
The "Domain" is a special case, used strictly by Dynamic VM creators, and similar tools. In this case, the AppID owner specifies that his AppID may deployed on any in a specific domain, such as "*.vmgroup.onap.org". This approval requires special ILM exception as well as AAF approval, and when accepted, the permission "org.onap.aaf.ca|aaf|domain" is grant
...
> java -jar /opt/app/cadi/1.3.2/lib/cadi-aaf-1.3.2-full.jar place a123@myapp.onap.org "*.vmgroup1.onap.org:test123.vmgroup1.onap.org:san1.onap.org:san2.onap.org"
Hardware Security in AAF
| View file | ||||
|---|---|---|---|---|
|