Skip to end of metadata
Go to start of metadata

FRANKFURT UPDATE for Configurations - AAF Agent

Topic: Demo of AAF-Hello, which demonstrates how to use the AAF Agent for Auto-configuration for Frankfurt.  

  • Note: AAF Version: 2.1.20
  • Covers JDK 11 update
  • Covers running YOUR container Non-root
  • The video uses some short hand commands, which are setup as Bash Functions and Aliases for AAF.  These are available on the following page as well.

Frankfurt Docker Agent Video Page


Original Video for Configuration

Developer Instructions for creating Configurations, Certificates and Coding in Java.

Apologies for size... 369.4.  Will try to make smaller, or look into streaming options later.



  1. this seems to be the same video Jonathan posted on readthedocs, but we can make comments here.

  2. Although I didn't catch him actually saying it, the password for, which is used in the demo, is the same as the password for

  3. NOTE: when I download the script in my Mozilla browser, it saves it as  Seems to be the same file...

  4. the agent script attempts to run docker image onap/aaf/aaf_agent:2.1.2-SNAPSHOT  but that is not in nexus3 at this time.

    1. So, using instructions here built a local copy.

      Used modified command:  mvn clean install -Dmaven.test.skip=true

      Stopped after step for ./ succeeded in creating local images.

      Then, returned to run the agent script, which ran but gave me a mixed result.  i.e. it seemed to create certificate-related files in local but ultimately gave me a 404 for the UserRole not found.  (I was using Role  so back to GUI to see what is the correct value....)   Any files that had been downloaded seem to have been removed upon getting the error.

      1. Never did discover the reason for the 404 I saw.  Stopped investigating when I found the generated files...

    2. As of 8/15, I see these containers in nexus3, so no need to build locally!

  5. Notice in the video that Jonathan is in /opt/app/osaaft directory when he invokes bash

    but after the container starts and does it's work, he is now in a bash shell within the container in /opt/app/osaaft/local.  This is where he zips things up and copies to the docker host.

    This didn't happen for me.  That is, the container ran, seemed to do something, and then exited without a trace - it didn't even show up in docker ps -a output.   I was left in my original directory on docker host.

    However, I finally did find the generated files in /var/lib/docker/volumes/bc_local   where bc_local was the value I used for VOLUME.  

    1. Thanks Dominic Lunanuova for the pointers! Was able to get the container build and certificate generated.

      The 404 is due to missing role assignment ("") under dcae namespace which is used in testing by default.

    2. I think you may be missing the "bash" argument to the script (note the last line in script).   It needs the "bash" argument to go into interactive mode, ie:  "bash ~/bin/ bash".    The bash opens in the "/opt/app/osaaf/local" directory of the container that has the generated files.

      1. correct!  ...glad there was a reasonable explanation.  I was uncomfortable with how this "just worked"...

  6. Q: All passwords are properly encrypted in props files for cadi library. But how would I decrypt password to allow a non-cadi server (e.g. embedded Jetty server) to use the SSL certificate?

    1. Passwords were generated by AAF, so Jonathan wouldn't have provided them to us via backchannel as he did for Beijing.

      Steps to see them on the docker host:

      1. Assumption: as noted above, built the aaf repo on this docker host.  FWIW, I built in home directory: /home/dgl/workspace/aaf.Certs
      2. Assumption: the files are in the docker volume directory on the docker host.  e.g. /var/lib/docker/volumes/bc_local   where bc_local was the value I used for VOLUME.  NOTE: in the AAF GUI certificate credential page, I had checked off both p12 and jks, so there are more files below than Jonathan's video example.  My directory looked like this:
        /var/lib/docker/volumes/bc_local/_data/local# ls
        org.onap.dmaap-bc.chal                               org.onap.dmaap-bc.p12                                   truststoreONAPall.jks                               org.onap.dmaap-bc.jks             org.onap.dmaap-bc.props
        org.onap.dmaap-bc.cred.props                             org.onap.dmaap-bc.keyfile
        org.onap.dmaap-bc.cred.props.6790791005515543627.backup  org.onap.dmaap-bc.location.props

      3. Assumption: if you followed Jonathan's example, the paths in the .props files are /opt/app/osaaf/local.  e.g. contents of org.onap.dmaap-bc.props:
        /var/lib/docker/volumes/bc_local/_data/local# cat org.onap.dmaap-bc.props
        # Configuration File generated on Thu Aug 02 20:04:00 UTC 2018

      4. Because of assumption 3, copy the files into /opt/app/osaaf/local so they are where cadi will look for them.
      5. Update the Java truststore on the docker host so it recognizes the SSL cert used by   I used this script:;a=blob;f=misc/;h=a9098956007d21d3cd3df8a5db73deac2da9db28;hb=66babf21bfc92ab0b522284ca8435a1faafffafc
      6. Create a Role for your application and grant it permission to run "showpass" .  In AAF GUI, login as aaf_admin and select "Command Prompt".  Where it says "Type your AAFCLI commands here" enter  (replace dmaap-bc with value for your app's namespace):
        1. role create org.onap.dmaap-bc.seeCerts
        2. role user add org.onap.dmaap-bc.seeCerts
        3. perm grant org.onap.dmaap-bc.certman local request,ignoreIPs,showpass org.onap.dmaap-bc.seeCerts
      7. cd /opt/app/osaaf/local
      8. Run the showpass command to see the set of passwords.  As far as I could tell, the last arguments to the command are your app's FQI and the app's FQDN:
        /opt/app/osaaf/local# java -jar /home/dgl/workspace/aaf.Certs/authz/cadi/aaf/target/aaf-cadi-aaf-2.1.2-SNAPSHOT-full.jar cadi_prop_files=./org.onap.dmaap-bc.props  showpass dmaap-bc
        2018-08-02T21:41:56.753-0400: Trans Info
                 REMOTE Show Password 2550.5276ms

      1. Thanks. None of these password can be used to list truststoreONAPall.jks; were you successful in integrating the generated cert with your application?

        1. RE: listing the certs using the output from showpass - mixed success.


          1. I was greedy in the AAF GUI cert self-serve step, and checked both p12 and jks.  In my props file, I got double entries for the cadi_keystore fields.  But showpass only output  one value, which was for the last property.
          2. The clear passwords output by showpass tend to have special chars which need to be escaped in shell commands.  e.g. Note 4b & 5b below.
          3. myshowpass output didn't include a value for truststoreONAPall.jks.   I tried to apply the other passwords to this file but they failed.   ...but not clear what that file is for anyway.  There was no reference to it in the props files.
          4. I was able to list the server certificate using the pwd from showpass:
            1. value in the props file:



            2. keytool output (using showpass output cadi_keystore_password=GeneratedPasswordNotPastedToWikiArticle ):
              # keytool -list -v -keystore /opt/app/osaaf/local/org.onap.dmaap-bc.p12 -storepass 'GeneratedPasswordNotPastedToWikiArticle'
              Keystore type: JKS
              Keystore provider: SUN

              Your keystore contains 1 entry

              Alias name:
              Creation date: Aug 2, 2018
              Entry type: PrivateKeyEntry
              Certificate chain length: 2
              Owner: C=US, O=ONAP, OU=OSAAF,, EMAILADDRESS=, CN=dmaap-bc
              Issuer: CN=intermediateCA_7, OU=OSAAF, O=ONAP, C=US
              Serial number: 4c8612025f0c8caf
              Valid from: Thu Aug 02 16:08:04 EDT 2018 until: Sat Feb 02 15:08:04 EST 2019
              Certificate fingerprints:
                   MD5:  49:88:CF:1B:09:05:DF:76:C5:D3:64:4F:02:B5:7C:7E
                   SHA1: D1:53:95:C8:88:F9:EE:30:55:A4:3E:CA:84:44:DD:9A:F8:1D:D1:3E
                   SHA256: 27:9B:1E:38:16:9F:72:8A:2A:34:B1:2F:DE:9A:62:2C:DE:BA:CC:08:28:38:E2:DE:F0:13:50:0B:86:4B:19:99
              Signature algorithm name: SHA256withRSA
              Subject Public Key Algorithm: 2048-bit RSA key
              Version: 3


              #1: ObjectId: Criticality=false
              AuthorityKeyIdentifier [
              KeyIdentifier [
              0000: 0F 10 14 E7 D3 67 F7 C4   AB 0B 6E 33 88 65 35 8A  .....g....n3.e5.
              0010: 70 93 43 93                                        p.C.
              [C=US, O=ONAP, OU=OSAAF]
              SerialNumber: [    05]

              #2: ObjectId: Criticality=false
                PathLen: undefined

              #3: ObjectId: Criticality=true
              ExtendedKeyUsages [

              #4: ObjectId: Criticality=true
              KeyUsage [

              #5: ObjectId: Criticality=false
              SubjectAlternativeName [
                DNSName: dmaap-bc
                DNSName: dmaap-bc.onap dbc.onap dmaap-bc dmaap-prov dmaapbc dmaap-listener.onap dbc-prov
              <remaining output cut>

          5. I was able to list the cadi truststore certificate using the pwd from showpass:
            1. value in the props file



            2. keytool output (using showpass output cadi_truststore_password=GeneratedPasswordNotPastedToWikiArticle):

              # keytool -list -v -keystore /opt/app/osaaf/local/ -storepass 'GeneratedPasswordNotPastedToWikiArticle'

              Keystore type: JKS

              Keystore provider: SUN

              Your keystore contains 1 entry

              Alias name: ca_local_0

              Creation date: Aug 2, 2018

              Entry type: trustedCertEntry

              Owner: C=US, O=ONAP, OU=OSAAF

              Issuer: C=US, O=ONAP, OU=OSAAF

              Serial number: 9eaeedc0a7ceb59d

              Valid from: Thu Apr 05 10:15:28 EDT 2018 until: Wed Mar 31 10:15:28 EDT 2038

              Certificate fingerprints:

                   MD5:  77:EB:5E:94:2E:B7:A3:45:97:6C:87:FE:A7:F7:64:0F

                   SHA1: 90:25:D1:D3:8B:3C:BE:2C:73:E9:6C:1A:48:5B:06:A8:39:0D:54:3B

                   SHA256: 1F:C2:BB:F6:7E:11:6F:F0:4C:C3:D9:6C:73:E5:99:B7:CA:7D:4D:EF:AA:6C:69:46:0D:2C:7B:A9:E4:23:5F:EA

              Signature algorithm name: SHA256withRSA

              Subject Public Key Algorithm: 4096-bit RSA key

              < remaining output cut>

          6. Will attempt to use the cert with my app (running embedded Jetty to see how it behaves) and report results here.

          1. Yes, I was able to validate the cert and looks okay so far.


            0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying
            * Connected to localhost ( port 8443 (#0)
            * ALPN, offering http/1.1
            * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
            * TLSv1.2 (OUT), TLS header, Certificate Status (22):
            } [5 bytes data]
            * TLSv1.2 (OUT), TLS handshake, Client hello (1):
            } [512 bytes data]
            * TLSv1.2 (IN), TLS handshake, Server hello (2):
            { [81 bytes data]
            * TLSv1.2 (IN), TLS handshake, Certificate (11):
            { [2246 bytes data]
            * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
            { [333 bytes data]
            * TLSv1.2 (IN), TLS handshake, Server finished (14):
            { [4 bytes data]
            * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
            } [70 bytes data]
            * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
            } [1 bytes data]
            * TLSv1.2 (OUT), TLS handshake, Finished (20):
            } [16 bytes data]
            * TLSv1.2 (IN), TLS change cipher, Client hello (1):
            { [1 bytes data]
            * TLSv1.2 (IN), TLS handshake, Finished (20):
            { [16 bytes data]
            * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
            * ALPN, server did not agree to a protocol
            * Server certificate:
            * subject: CN=dcae; emailAddress=;; OU=OSAAF; O=ONAP; C=US
            * start date: Aug 2 23:08:09 2018 GMT
            * expire date: Feb 2 23:08:09 2019 GMT
            * issuer: C=US; O=ONAP; OU=OSAAF; CN=intermediateCA_7
            * SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
            * Server auth using Basic with user 'sample1'
            } [5 bytes data]
            > POST /eventListener/v5 HTTP/1.1
            > Host: localhost:8443
            > Authorization: Basic c2FtcGxlMTpzYW1wbGUx
            > User-Agent: curl/7.46.0
            > Accept: */*
            > Content-Type: application/json
            > Content-Length: 483
            } [483 bytes data]
            * upload completely sent off: 483 out of 483 bytes
            { [5 bytes data]
            < HTTP/1.1 200
            < X-Rathravane: ~ software is craft ~
            < Content-Type: application/json;charset=ISO-8859-1
            < Content-Length: 18
            < Date: Tue, 07 Aug 2018 21:12:52 GMT
            { [18 bytes data]
            100 501 100 18 100 483 21 573 --:--:-- --:--:-- --:--:-- 573

          2. After modifying AAF Certificate setup to only have jks (and not p12), and use the showpass command as above, was able to configure an embedded Jetty app to use the clear password and dump the certificate contents using openssl request (from that same host):

            $ openssl s_client -connect localhost:8443 2>&1 | openssl x509 -text | grep DNS
                            DNS:dmaap-bc, DNS:dmaap-bc.onap dbc.onap dmaap-bc dmaap-prov dmaapbc dmaap-listener.onap dbc-prov

          3. The truststoreONAPall.jks is the JDK one plus a couple aai ones and the aaf root:  ..   

            Your keystore contains 107 entries
            onaptestca, Apr 17, 2018, trustedCertEntry, 
            oldaaiinter, Apr 19, 2018, trustedCertEntry,
            oldaairoot, Apr 19, 2018, trustedCertEntry,
            The password is "changeit" which is the default one used in a JDK installation:  

            keytool -list -keystore truststoreONAPall.jks -storepass changeit
  7. Next will be to figure out how to set the CN and SAN dynamically. I can see this can be updated via AAF Gui.. If there is way to specify this through script execution, will be better.

  8. Just found this comment thread. Trying to understand if any of this is applicable to my current observations. Using the above video and these docs for reference.

    Managed to work through some of the credentials issues as  described earlier in the comments.

    The software does not behave as described in the video and so I am having trouble proceeding.

    The that we downloaded and renamed does not automatically execute the commands in the container as described in the video even with the 'bash' argument.  In order to proceed, I did the following 

    • Added aaf-cm to /etc/hosts (due to an error message when executing the following step)
    • Executed  /opt/app/aaf_config/ (total shot in the dark)

    Results attached. - 

    Then copied the following to my local (Mac)

    • /opt/app/osaaf/local
    • /opt/.aaf

    And ran the sample app from the video. results are attached.



    Update 02/29/2019:

    cadi_truststore_password encoded in theorg.onap.oof.cred.props file did not decrypt properly. Removed the property from the file in order to default to 'changeit' to resolve the Keyfile password issue.

    Now having an issue with the aaf_id and aaf_password in the same file. Get the following result regardless of the credentials provided

    2019-02-19T10:47:31.411-0500: Error reading location information from 403 <html>


    <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>

    <title>Error 403 Access Denied</title>


    <body><h2>HTTP ERROR 403</h2>

    <p>Problem accessing /locate/AAF_NS.token:2.1. Reason:

    <pre>    Access Denied</pre></p><hr><a href="">Powered by Jetty:// 9.4.12.v20180830</a><hr/>


    Same result with

    • Original credentials ( with the encoded password
    • Original credentials with password in clear 
    • Original credentials with invalid password in clear
    • with password in clear
    • with password in clear
    • Noted  in debugger that ! in the password was encoded as  %21 so forced it in the debugger to ! with the same result
  9. Hi.  I am trying to run SimpleRestClientExample by following instructions from the video. I am able to generate certificate but I am getting  CadiException in SimpleRestClient after unsuccessful call  to  https://aaf-token:8140/ endpoint (error code 404) .  Any ideas how to resolve it?