Skip to content

MF Remittance Certificate Renewal

Background:

  • Remittance has a provider named Uniteller. Remittance keeps a mTLS communication with Uniteller endpoints. That means we share a majority certificate be-mf-remittance with them.
  • Our current certificate is shared with Uniteller team but additionally, we generate .crt and .key files from the be-mf-remittance certificate and send them in every single request to Uniteller endpoints.

Technical Details

Problem:

  • Majority certificates currently expires after 3 months. So that means, we have to share them with Uniteller team every 3 months, that is not ideal from both parties.
  • Additionally, to generate a new majority certificate for be-mf-remittance, we need to create a PR in platform-infrastucture repository. So that means, every 3 months the same PR create, that is not efficient.
  • Finally, once we generate the new Majority certificate for be-mf-remittance, then we need to refresh the .crt and .keys files in the following path /etc/ssl/certs/remittance-tls/tls.crt. That is a manual step we have to do every 3 months, that is not efficient too.

Solution: 

We need to find a license or a tool to be able to create Majority certificate with an expiration higher than 3 months (ideally 1-3 years).

MF Remittance Certificate Renewal

Background

  • The Remittance service integrates with Uniteller using mutual TLS (mTLS).
  • We share the be-mf-remittance certificate with Uniteller.
  • In addition, we generate .crt and .key files from this certificate, which are attached to every request sent to Uniteller endpoints.

Technical Details

  • Certificate loading is implemented in the HTTP client handler (code reference).
  • Currently, the generated .crt and .key files are stored at:

/etc/ssl/certs/remittance-tls/

Current Challenges

  • Short validity: Majority certificates expire every 3 months. This requires frequent re-issuance and coordination with the Uniteller team.
  • Manual process: Each renewal requires a PR in the platform-infrastructure repository, followed by manual updates of .crt and .key files on the service host.
  • Operational overhead: The cycle repeats quarterly, creating unnecessary inefficiencies for both Majority and Uniteller.

Proposed Solution

Adopt a licensing option or tool that allows creation of longer-lived certificates for be-mf-remittance (ideally with a validity period of 1–3 years). This would reduce manual intervention, eliminate repetitive PRs, and improve overall operational efficiency.