Client in multi ePO bridged infra

    Hi


    I have a client that the cert has been signed by one of the ePO servers that are bridged together.

    With this cert i am able to connect only to brokers provisioned by the same ePO. No other broker lets me in.

    Do you have any hints or troubleshooting steps for such an issue?


    Regards PG

    Due to security reasons, there is no automated way to do this and the steps depend on how you provisioned your certificate.


    1. If you used your own CA/certificate then you have to upload it to the other ePO in Server Settings->DXL Certificates (Third Party).

    You have to wake up all the brokers in the other ePO to update their keystore.


    2. If you used the dxlclient provisionconfig , then your certificate is signed by the OpenCA and you can only get that from the DXL Broker keystore.

    You can get that from any broker from the other ePO that you want to connect to so it does require an administrator to get that file.

    If you would like to take this approach then let us know and we can provide more steps.


    Thanks

    Viji

    Hi


    The certificate has been signed by the EPO and exported, used then in the configuration of a client. Once connecting to a broker managed by other EPO, the error says: "unknown CA"


    Thanks

    Pawel

    It sounds like you are using the CLI option outlined here: Command Line Provisioning (CLI). To use client certificates generated using this method across brokers managed by different ePO Servers in a Multi-ePO DXL fabric, you would need to access the keystore on the brokers themselves, which we don't recommend unless absolutely required. Please let us know if you need more information about this particular method.


    An easier and safer option for enabling clients to connect to brokers managed by different ePO Servers on a Multi-ePO DXL fabric is to generate your own CA and import it in the DXL Certificates (Third Party) section of the ePO Server Settings. If that option works for your environment, please see the following instructions:


    (Found under External Certificate Authority (CA) Provisioning in the Data Exchange Layer (DXL) Python SDK Documentation)

    1. Certificate Files Creation (PKI)
    2. ePO Certificate Authority (CA) Import
    3. ePO Broker Certificates Export
    4. ePO Broker List Export
    5. Repeat Step 2 on the other ePO Servers on your Multi-ePO DXL fabric (using your new third party CA)
    6. Use Agent Wake-Up prompt the brokers to check for updates
    7. Connect your client to any broker managed by an ePO that has your third-party CA

    Thanks for the information


    I will try with the External CA in all the managed EPOs. But one question comes, shouldn't the connected ePOs handle the certificate exchange between the brokers? As the ePOs are connected, i expected and understood the communication between them holds as well the certificate exchange. But i see that in the keystore the CA ODXL_CA is not being transfered, and i suppose this lead to the issue.

    Pawel,


    Like you mentioned , the certificates that allows clients which are MA managed, are exchanged between the connected ePO servers.

    Regarding the Open CA, since there is currently no easy ways for admins to see open clients especially from other ePO servers. So this was intentionally not exchanged.


    When you import the certificate, it is visible in the UI and the admin is aware.


    If you see a use case where this will be needed in a production environment , we can consider ways to make this easier.


    Thanks

    Viji

    Hi Viji


    Thanks for the information

    One thing is then misleading. Once you export the configuration for a DXL Client from the ePO, you receive a full bunch of certs and broker information. If the CAs information that signed the oDXL client cert is not exchanged between the all the brokers, managed by different ePOs, then once exporting, there should be only the certificates and the brokers listed, necessary to establish such connection. So i would expect only the certificates of the signing ePO and the brokers managed by the signing ePO.

    We can see how the current functionality of the certificate export/import for multi-ePO fabrics could lead to confusing circumstances when combined with OpenDXL's built-in provisioning. Our team will have to take some time to evaluate if a change (or customization) to this feature would reduce the potential for misunderstandings.