Automic Workload Automation

 View Only
Expand all | Collapse all

Certificates approach in V21

  • 1.  Certificates approach in V21

    Posted Oct 11, 2022 05:47 AM
    Hi Team,

    Has anyone used wildcard certificates to implement V21?

    We are using Public CA wildcard certificates so that we can use the same across different environments. There is no issue with JCP & AWI but we are getting the below error for Agents. I've found a KB that says we need to define the hostname, IP in SAN but we don't want to do that as we are intending to use the same certificates across environments.

    Unix Agent Error - KB

    20221011/114859.810 - U02000376 Could not parse certificate 'wildcard_cert.pem'. Please make sure that the certificate is iPEM format.
    20221011/114859.810 - U02000398 Loading certificates from the directory 'directory' that is specifiedn the parameter'AgentSecurityFolder'.\
    20221011/114859.811 - U02000377 Certificate loaded from file 'agent_security.pem'.
    20221011/114859.821 - U02000313 Communication error with partner '*SERVER', error: 'TLS-handshake/337047686(certificate verify faid (SSL routines, tls_process_server_certificate))'.
    20221011/114859.821 - U02000010 Connection to Server 'AE21/IP:8443' terminated.


    ------------------------------
    Thanks & Regards,
    Bharath B.
    ------------------------------


  • 2.  RE: Certificates approach in V21

    Broadcom Employee
    Posted Oct 12, 2022 02:23 AM
    Edited by Markus Embacher Oct 12, 2022 02:24 AM
    Hi Bharath,

    what is the wildcard specification in your certificate and what is the connection= parameter that the agent uses to connect to the Automation Engine?

    Regards, Markus


  • 3.  RE: Certificates approach in V21

    Posted Oct 12, 2022 02:36 AM
    Hi Markus,

    We are using *.domain.com in our certificate and hostname.domain.com:8443
    in the connection field.

    Thanks & Regards,
    Bharath B.




  • 4.  RE: Certificates approach in V21

    Broadcom Employee
    Posted Oct 12, 2022 02:40 AM
    Since you are using a public signed certificate: where is the matching CA root certificate located on the agent server?


  • 5.  RE: Certificates approach in V21

    Posted Oct 12, 2022 02:55 AM
    They are stored under /var/ssl/certs and I have given that in SSLCertDir
    parameter




  • 6.  RE: Certificates approach in V21

    Broadcom Employee
    Posted Oct 12, 2022 03:00 AM
    If that is an AIX server, then please leave that configuration empty. The agent searches automatically for following folders:

    Default SSLCertDir

    • /etc/ssl/certs

      Platforms: Debian/Ubuntu

    • /etc/pki/tls/certs

      Platforms: Fedora/RHEL/CentOS

    • /usr/local/share/certs

      Platforms: FreeBSD

    • /etc/openssl/certs

      Platforms: NetBSD

    • /var/ssl/certs

      Platforms: AIX




  • 7.  RE: Certificates approach in V21

    Posted Oct 12, 2022 03:14 AM
    It's still the same. The *could not parse the pem file error *for the
    *agentname.pem* file in security folder is still there.

    Note: the agentname.pem file contains the root, intermediate and server
    certificate details. The other acutual pem file that is placed in
    /var/ssl/certs also contains the same. Do I have to configure anything else
    extra?




  • 8.  RE: Certificates approach in V21

    Broadcom Employee
    Posted Oct 12, 2022 06:43 AM
    Edited by Markus Embacher Oct 12, 2022 06:43 AM
    The error message is misleading. Kindly double check the content of the CA root certificate in the /var/ssl/certs folder if it matches the certificate which has been used to sign your server certificate.


  • 9.  RE: Certificates approach in V21

    Posted Oct 19, 2022 01:17 AM
    Update: I'm able to install SQL, DB Service, TLS Gateway and Windows Agents without any issue.

    It seems the issue is occurring only with the AIX Agents.

    Also, for other agent types I'm able to see message like 

    U02000379 Initiating connection to server 'hostname.domain.com:8443' using WebSocket URI: 'wss://hostname.domain.com:8443/agent'.

     However, for the AIX agents it is showing System name as server instead of the actual hostname.domain.com 

    U02000379 Initiating connection to server 'AE21' using WebSocket URI: 'hostname.domain.altayer.com:8443/agent'.




    ------------------------------
    Bharath B.
    ------------------------------



  • 10.  RE: Certificates approach in V21

    Broadcom Employee
    Posted Oct 19, 2022 02:33 AM
    Edited by Markus Embacher Oct 19, 2022 07:15 AM
    Hi,
    are you running the AE on the same server (AIX) too? If yes please share the version of the JAVA runtime.
    Have you opened a case about the issue happening specifically on AIX?
    Thank you!  


  • 11.  RE: Certificates approach in V21

    Posted Nov 03, 2022 12:51 PM
    this error is a very generic error and could have been for any reason. some advice below

    make sure TCP/IP section = connection=automationEnginehost:8443
    put them all certs in path include = .key , automic.crt , .p12 , companyinternal.crt , .pfx ...
    fill AUTHORIZATION section = trustedCertFolder , agentSecurityFolder , keyPassword


    ------------------------------
    Olgun Onur Ozmen
    https://www.linkedin.com/in/olgunonurozmen/
    ------------------------------



  • 12.  RE: Certificates approach in V21

    Broadcom Employee
    Posted Feb 02, 2023 02:22 AM
    Edited by Markus Embacher Feb 02, 2023 02:23 AM
    Hi,

    for Linux/Unix agents there seems to be an issue in some cases with reading the CA root certificates from the OS standard location. As a workaround please try configuring 
    trustedCertFolder=/var/ssl/certs
    for your AIX agent.

    Make sure you configure the hostname= paramter in ucsrv.ini and set it to the AE server name that matches your server certificate.

    Please note that the JCP basically replaces the CP. Define as many WS.PORT ports in ucsrv.ini as you had CP ports in 12.3. Check whether you still require a CP at all (still running 12.3 agents? using the AS/400 or z/OS agent? using the CALL-API?). 

    Regards, Markus