Skip to content

Conversation

@ktechmidas
Copy link
Contributor

Issue being fixed or feature implemented

ZeroSSL certificate IDs were unnecessarily stored in AWS SSM Parameter Store, adding complexity and AWS dependencies for
non-sensitive data. Certificate IDs are public identifiers that don't require secure storage, unlike API keys which should remain
secret.

What was done?

  • Extracted ZeroSSL certificate IDs from AWS SSM and added them directly to testnet.yml under each HP masternode configuration
  • Simplified the dashmate ZeroSSL role by removing all AWS SSM lookups and updates for certificate IDs
  • Maintained backwards compatibility - self-signed certificates for other networks (mainnet-support, devnet) remain unchanged
  • Added robust error handling for networks without hp_masternodes or certificate IDs defined

Key changes:

  • Modified ansible/roles/dashmate/tasks/ssl/zerossl.yml to read certificate IDs from local hp_masternodes config instead of AWS SSM
  • Updated networks/testnet.yml with certificate IDs for all HP masternodes (except hp-masternode-2 which has no certificate)
  • Removed complex fallback logic and AWS dependencies from certificate management

How Has This Been Tested?

  • Verified certificate ID extraction from AWS SSM for all testnet HP masternodes
  • Tested variable access patterns using test playbooks to ensure hp_masternodes[inventory_hostname]['zerossl_certificate_id'] works
    correctly
  • Validated different network scenarios:
    • Testnet with certificate IDs → uses ZeroSSL with local config
    • Mainnet-support without certificate IDs → uses self-signed certificates (unchanged)
    • Networks without hp_masternodes defined → gracefully handles missing data
  • Confirmed SSL provider logic remains intact (zerossl for testnet, self-signed default for others)

Breaking Changes

None. This change is backwards compatible:

  • Networks using self-signed certificates continue to work unchanged
  • ZeroSSL functionality is preserved, just sourced from local config instead of AWS SSM
  • All existing deployment workflows remain functional

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have made corresponding changes to the documentation

For repository code-owners and collaborators only

  • I have assigned this pull request to a milestone

Copy link
Collaborator

@vivekgsharma vivekgsharma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants