z/OS Communications Server

z/OS Communications Server

z/OS Communications Server

A high-performance foundation for building and deploying networking applications on z/OS

 View Only

  • 1.  AT-TLS, Keyrings, and Certificate management

    Posted Tue January 28, 2025 03:57 PM

    We are currently in the process of implementing AT-TLS, and as more vendor sites are requiring secure connections for FTP connections, we are accumulating a number of their certificates. Given this, we are looking to understand the best practices for storing these certificates. Specifically, should each vendor have its own keyring to manage their certificates independently, or is it advisable to consolidate all vendor certificates under a single 'FTP' keyring? Additionally, are there any security or management implications associated with either approach that we should consider?

    In practice, it seems like the best route might be creating a policy for each vendor while also maintaining a generic FTP policy. The vendor-specific policy would have a higher priority than the general FTP client one. With each vendor policy, we can customize it to a specific keyring, but is that necessary? Can there be one master keyring to hold all the vendor certificates?

    For example:

    • Keyring.IBM

      • IBMcert1

    • Keyring.Broadcom

      • broadcomcert1

    • Keyring.BMC

      • bmccert1

    Or:

    • Keyring.FTPC

      • IBMcert1

      • broadcomcert1

      • bmccert1

    Any insights or recommendations on the best practice for this would be greatly appreciated.



    ------------------------------
    Christian Gonzalez
    ------------------------------


  • 2.  RE: AT-TLS, Keyrings, and Certificate management

    Posted Wed January 29, 2025 02:54 AM
    I believe the best practice is to have keystores and trust stores.

    The keystore has the private key used to identify the server.    You might have a different keystore for online banking and z/OSMF

    The trust stores are for the CA certificates from the systems you work with. 
    People often use just one combined trust/keystore which is common, but not good practice as it does not provide isolation.  If you can logon to this app - you can logon to that app which may not be what you wanted.

    For your internal organisation it is good to have one combined trust store for online banking and z/OSMF.   This reduces the admin of certificate maintenance.  Otherwise the risk is you get a lot of these trust stores, and there may be trust stores you do not know about, and so you cannot maintain (such as remove bad CAs).
    A keystore should have the private key used by applications with similar requirements, so different bank servers might use the same keystore, but use a different keystore between online banking and z/OSMF applications.

    If you have different groups of users, such as the companies you mention,  you may want to have separate trust stores, so someone from company1 cannot do a certificate logon to a site just to application2 because the CA for company1 is not in the trust store for application2.

    You might also want to think about using client certificates to authenticate users.  Some schemes work better than others (from an admin/coding perspective).  This may influence the number of trust stores you have.

    I'd welcome other views

    Just my h'pence

    Colin



    Original Message


  • 3.  RE: AT-TLS, Keyrings, and Certificate management

    Posted Wed January 29, 2025 09:20 AM

    I would say that it depends what it is you are trying to achieve and what you trust. Talk to your local security administrator.

    If trust to root certificate is only needed then one keyring is more then enough, and one AT-TLS rule.  

    Ask about Root certificate that's my 2 cents 

    //Martin



    ------------------------------
    Martin Jonason
    ------------------------------

    Original Message


Related Content