Secure vs Non-Secure Deployments How the deployment security choice changes service exposure, certificate work, path design, and upgrade strategy.
In GoldenGate Microservices, secure versus non-secure is not a cosmetic wizard checkbox. It changes how Service Manager and the deployment services are exposed, whether TLS material is part of the deployment contract, how distribution paths can be secured, and how painful later hardening will become. Treat it as a deployment boundary decision, not a post-build tuning item.
How the described components fit into the goldengate operational model.
Intermediate to advanced oracle goldengate practitioners.
Confident operation and configuration of the described components.
What the secure versus non-secure choice actually controls
This choice governs the service-facing security posture of a Microservices deployment. In practical terms, it decides whether the deployment is built around a security profile and TLS-backed access, or whether management access remains plain HTTP. It also shapes how Distribution Service participates in secure inter-deployment paths because trust material is part of the deployment design instead of an afterthought. Treat it as a creation-time deployment characteristic, not as a minor option that can be corrected later without broader lifecycle impact.
TLS is part of the deployment contract
Server-side wallets, certificates, and trusted roots become deployment planning inputs. Access to Service Manager and Administration Service is expected to be HTTPS-based, and secure path creation depends on certificate trust between endpoints.
Management traffic stays lighter but exposed
The deployment can be created and used without the TLS security profile. That keeps setup simpler in labs, but the management surface is still fundamentally non-secure and must be treated as such in network design.
The decision is larger than browser login
It affects browsers, automation, Distribution and Receiver trust, target-initiated path options, and the feasibility of later hardening without a rebuild.
Deployment security mode answers how the Microservices endpoints are exposed and trusted. It does not replace separate decisions about database credential storage, schema privileges, initial-load handling, or whether trail data also needs its own protection strategy.
Many estates remember the browser URL but forget the deployment-level consequence. That is how a team ends up with a clean login page, insecure backend assumptions, and no certificate story for secure distribution later.
Secure deployment, non-secure deployment, and reverse proxy are not interchangeable designs
Reverse proxy belongs in this discussion because it often creates false confidence. A proxy can improve the front-door posture for Service Manager and Administration Service, but it does not magically convert a non-secure deployment into a full secure deployment. Distribution Service, Receiver Service, and Performance Metrics Service should not be designed as if reverse proxying gives them the same coverage.
| Design choice | Service Manager and Administration Service | Distribution and Receiver implications | Operational cost | Good fit |
|---|---|---|---|---|
| Secure deployment | Built around HTTPS access and a deployment security profile. | Secure path design can use trusted certificates between deployments, including secure target-initiated flows when both sides are secure. | Requires wallet, certificate, trust, renewal, and hostname discipline. | Production, regulated estates, cross-host replication, any environment meant to survive audits or handoffs. |
| Non-secure deployment | Management pages remain reachable over HTTP when the security profile is not used. | Does not establish the secure path posture that later topologies may require. | Lower setup effort at first, higher hardening cost later. | Disposable labs, training systems, isolated proof-of-concept work. |
| Non-secure deployment plus reverse proxy | Users can be brought in through HTTPS at the proxy edge, but the underlying deployment was still created without the security profile. | Do not treat proxying as secure coverage for Distribution, Receiver, or Performance Metrics services. | Adds ingress infrastructure while leaving part of the security story unresolved. | Organizations standardizing ingress controls for UI/API access while they still understand the backend remains non-secure. |
The design mistake is assuming the third row is functionally equivalent to the first. It is not. A reverse proxy is an edge pattern. A secure deployment is a deployment posture.
HTTP should not be your management habit
Operators, scripts, and dashboards should all be trained around the secure endpoint identity from day one.
Network isolation becomes part of the control
You are compensating with host placement, ACLs, jump hosts, or short lifespan. Write those controls down or the deployment will drift into normal use.
Document what the proxy does not cover
That note prevents future teams from assuming Distribution and Receiver traffic has already been secured just because the browser address starts with HTTPS.
Planning a secure deployment before you ever launch the assistant
A secure deployment starts with identity planning, not with clicking a checkbox. Older GoldenGate training material makes this obvious: the secure deployment flow expects wallet and certificate preparation before the deployment assistant step where security is enabled. Current releases still reward the same discipline even though estates are larger and trust chains are more formal.
- Fix the host identity first. The fully qualified hostname used by operators and by peer deployments must match the certificate identity you intend to deploy.
- Choose the CA model early. Lab systems may tolerate private or self-signed roots, but production should use the organization's standard certificate issuance process and renewal controls.
- Prepare both server-side and Distribution Service client-side material. Secure topology design often needs more than one wallet because outbound path authentication is its own concern.
- Freeze the port map. Service Manager, Administration Service, Distribution Service, Receiver Service, and any Performance Metrics listener should be known before firewall work begins.
- Decide whether access is direct or fronted by reverse proxy. The answer changes both certificate placement and the way operators discover URLs.
Older secure deployment labs show the key pattern clearly: at deployment creation time the security step points at an existing server wallet and, when secure outbound distribution is part of the design, an existing Distribution Service client wallet. That is why secure build work starts with certificate preparation.
If your certificate naming, trusted roots, and port plan are still unstable, every later symptom will look random: browser warnings, trust failures between deployments, stale automation URLs, or a proxy layer that no longer matches the service certificates underneath it.
orapki wallet create \ -wallet /u02/ogg/wallet/root_ca \ -auto_login \ -pwd 'ChangeMe1!' orapki wallet add \ -wallet /u02/ogg/wallet/root_ca \ -dn "CN=GGRootCA" \ -keysize 2048 \ -self_signed \ -validity 3650 \ -pwd 'ChangeMe1!' orapki wallet export \ -wallet /u02/ogg/wallet/root_ca \ -dn "CN=GGRootCA" \ -cert /u02/ogg/wallet/rootCA_cert.pem \ -pwd 'ChangeMe1!' orapki wallet create \ -wallet /u02/ogg/wallet/nova_srv \ -auto_login \ -pwd 'ChangeMe1!' orapki wallet add \ -wallet /u02/ogg/wallet/nova_srv \ -dn "CN=ggma-hub01.example.net" \ -keysize 2048 \ -pwd 'ChangeMe1!' orapki wallet export \ -wallet /u02/ogg/wallet/nova_srv \ -dn "CN=ggma-hub01.example.net" \ -request /u02/ogg/wallet/nova_srv_req.pem \ -pwd 'ChangeMe1!' orapki cert create \ -wallet /u02/ogg/wallet/root_ca \ -request /u02/ogg/wallet/nova_srv_req.pem \ -cert /u02/ogg/wallet/nova_srv_cert.pem \ -serial_num 20 \ -validity 365 \ -pwd 'ChangeMe1!' orapki wallet add \ -wallet /u02/ogg/wallet/nova_srv \ -trusted_cert \ -cert /u02/ogg/wallet/rootCA_cert.pem \ -pwd 'ChangeMe1!' orapki wallet add \ -wallet /u02/ogg/wallet/nova_srv \ -user_cert \ -cert /u02/ogg/wallet/nova_srv_cert.pem \ -pwd 'ChangeMe1!' orapki wallet create \ -wallet /u02/ogg/wallet/dist_client \ -auto_login \ -pwd 'ChangeMe1!' orapki wallet add \ -wallet /u02/ogg/wallet/dist_client \ -dn "CN=ggma-hub01.example.net" \ -keysize 2048 \ -pwd 'ChangeMe1!' orapki wallet export \ -wallet /u02/ogg/wallet/dist_client \ -dn "CN=ggma-hub01.example.net" \ -request /u02/ogg/wallet/dist_client_req.pem \ -pwd 'ChangeMe1!'
Prepare wallets and trust roots
Finish certificate material before deployment creation so the secure deployment flow has stable inputs instead of placeholders.
Create the deployment in secure mode
During the security step in the assistant, point the deployment at the server wallet and the Distribution Service client wallet that were prepared for this environment.
Finish the service and database settings
Only after the security posture is fixed should you finalize the listener ports, administrator identity, database registration, and workload onboarding.
Verification after a secure build should prove trust, not just process state
A green deployment dashboard is not enough. Verification must prove that the right certificate material is present, the right listeners are exposed, the right protocol is in use, and the right side trusts the right remote certificate for any secure path design. Check from the wallet level outward, then from the network edge inward.
orapki wallet display \ -wallet /u02/ogg/wallet/nova_srv \ -pwd 'ChangeMe1!' orapki wallet display \ -wallet /u02/ogg/wallet/dist_client \ -pwd 'ChangeMe1!' ss -ltnp | egrep '16000|16001|16002|16003|16004' openssl s_client \ -connect ggma-hub01.example.net:16000 \ -servername ggma-hub01.example.net \ -showcerts openssl s_client \ -connect ggma-hub01.example.net:16001 \ -servername ggma-hub01.example.net \ -showcerts
| Checkpoint | What to inspect | Expected signal | What it means if it fails |
|---|---|---|---|
| Wallet integrity | Display the server and Distribution Service client wallets. | The intended user certificate and trusted certificate entries are present. | The deployment or secure path will later fail for reasons that look like transport issues but are really trust-store defects. |
| Management access | Open Service Manager and Administration Service using the planned secure URLs. | Operators use HTTPS as the normal control-plane entry point. | Either the wrong endpoint inventory is in circulation or the deployment was not built with the posture the team thinks it has. |
| Certificate presentation | Probe the listener with openssl s_client. |
The certificate identity and chain match the host that operators and peer deployments are meant to reach. | Expect hostname mismatches, trust warnings, or broken path establishment later. |
| Secure source-initiated path readiness | Confirm the source deployment trusts the target deployment certificate. | The source side can establish a secure outbound session to the target. | Distribution path creation or startup will fail once it reaches the trust boundary. |
| Secure target-initiated path readiness | Confirm both deployments are secure and the target trusts the source certificate. | The target side is eligible to initiate the secure pull correctly. | Either the option will be unavailable in practice or the path will fail during connection setup. |
Start with trust material, then listeners, then browser or API reachability, and only after that test path creation. That order reduces noise because it proves the security substrate before you blame the path logic.
A team under time pressure often skips certificate inspection and jumps to process start attempts. That only converts a basic trust problem into a harder incident with more moving parts.
When a non-secure deployment is acceptable and when it is simply technical debt
Non-secure deployment still has a place, but the place is narrow. It can be reasonable for training, a disposable proof-of-concept, or a short-lived lab whose management interface never escapes a tightly bounded network segment. Outside those cases, it becomes deferred rework with a misleadingly low entry cost.
Non-secure can be reasonable when all of these are true
- The environment is non-production and has a clear retirement or rebuild date.
- Only a small operator set can reach the management surface.
- The topology does not depend on secure target-initiated distribution later.
- The team has written down the exit plan to a secure deployment before go-live.
It is debt when any of these are true
- The deployment is becoming a shared platform for multiple teams.
- Operations already assume HTTPS or certificate-based trust will appear later with little effort.
- The deployment participates in cross-host replication that should be treated as durable infrastructure.
- Audit, access review, or platform engineering ownership is starting to matter.
Isolation
If the deployment is non-secure, network placement and host access control are no longer secondary. They are part of the security design.
Short lifespan
Non-secure works best when everyone knows the environment is temporary and its migration path has already been chosen.
Honest documentation
State explicitly whether a reverse proxy only fronts the UI and whether backend services remain outside that protection boundary.
Non-secure deployments often outlive the sprint or migration window that justified them. Once scripts, bookmarks, operational habits, and data paths settle around them, the eventual security rebuild becomes larger than it would have been on day one.
Secure paths between deployments make security mode a topology concern
The real architectural consequence appears when one deployment must trust another. Current GoldenGate guidance is explicit here: for a secure source-initiated distribution path, the source deployment must trust the target certificate; for a secure target-initiated path, the target deployment must trust the source certificate; and secure target-initiated paths require both deployments to be secure. This is where a casual non-secure decision stops being local and starts constraining the topology.
| Path style | Trust action | Deployment mode requirement | Operational consequence |
|---|---|---|---|
| Secure source-initiated distribution | Import the target trusted certificate into the source deployment. | The source needs the trust material required to validate the target endpoint. | If the source certificate store is incomplete, the path problem will show up at connection time even if both deployments otherwise look healthy. |
| Secure target-initiated distribution | Import the source trusted certificate into the target deployment. | Both source and target deployments must be secure. | This requirement removes any illusion that one non-secure side can be left behind without affecting topology options. |
If a design roadmap includes secure path growth, partner onboarding, or target-initiated operation, secure deployment should be the default posture from the first build. Otherwise the estate eventually has to be redesigned while it is already carrying live operational assumptions.
Upgrade behavior turns old non-secure deployments into migration work
This is the lifecycle trap that matters most in mature estates. Oracle's upgrade guidance keeps the security mode unchanged for an existing non-secure Microservices deployment during upgrade. In other words, upgrading an old non-secure deployment does not quietly convert it into a secure one. If the target state must be secure, treat that as a migration design exercise rather than a hopeful upgrade checkbox.
Audit the old deployment honestly
Record whether operators reach it over HTTP, which scripts assume old endpoints, and whether any future topology requires secure target-initiated distribution.
Build the new secure deployment as a parallel target state
Prepare certificates, create the secure deployment cleanly, and make the new URL, trust, and port inventory explicit before workload migration begins.
Recreate and validate secure paths deliberately
Import trusted certificates on the correct side, test secure management access, and prove path behavior before any cutover window depends on it.
Cut over and retire
Move the operational contract to the new secure deployment, then decommission the old one instead of carrying two contradictory security models indefinitely.
Security hardening touches endpoints, trust stores, operator habits, and automation. When the original build was non-secure, a controlled parallel secure deployment is usually clearer than trying to pretend the lifecycle boundary never mattered.
Carry forward process definitions, path intent, database registration knowledge, and port ownership. Do not carry forward the mistaken assumption that upgrade itself solved the security posture.
The common failure patterns are nearly always trust or boundary mistakes
Secure versus non-secure incidents rarely start with a mysterious GoldenGate process defect. They usually start with a bad boundary assumption: the wrong certificate on the wrong side, a proxy mistaken for full deployment security, stale automation still calling the non-secure URL, or an upgrade plan that ignored the preserved posture of the original deployment.
Browser reaches the page but warns or refuses trust
The certificate chain or hostname identity presented by the service does not match the operator trust model for that endpoint.
Secure path design stalls at connection time
The deployment that must trust the remote side never received the correct trusted certificate.
Proxy access looks secure, but replication design still fails
The team secured the browser entry point and assumed that solved the Distribution and Receiver story as well.
Upgraded environment still behaves like HTTP-era infrastructure
That is usually expected behavior for a non-secure deployment that was upgraded without a separate migration to a secure deployment.
| Symptom | Likely cause | Inspect next | Next action |
|---|---|---|---|
| HTTPS page loads with warnings | The presented certificate is self-signed, privately issued without a trusted root on the client side, expired, or mismatched to the hostname in use. | The server wallet contents, root trust distribution, and the exact hostname operators are using. | Fix the trust chain or endpoint naming first. Do not treat the warning as cosmetic if the deployment is meant to be durable. |
| Source-initiated secure path cannot establish cleanly | The source deployment does not trust the target certificate. | The trusted certificates loaded into the source deployment and the target certificate actually presented. | Import the correct target trust material into the source deployment, then retest path creation or startup. |
| Target-initiated secure path plan will not work | One side is still non-secure or the target does not trust the source certificate. | The security mode of both deployments and the target-side trust store. | Secure both deployments first, then complete the trust exchange in the correct direction. |
| Operators think the proxy finished the hardening job | The design documentation never separated UI ingress security from deployment security mode. | Whether Distribution, Receiver, and Performance Metrics services were included in the security assumptions. | Rewrite the operating model and, if needed, rebuild the deployment posture instead of merely editing proxy routes. |
| Post-upgrade scripts still call HTTP endpoints | Upgrade preserved the original non-secure posture and the script inventory was never corrected. | Scripted URLs, bookmarks, monitoring targets, and the actual deployment mode. | Decide whether the environment stays intentionally non-secure or whether a migration to a new secure deployment is now overdue. |
Secure versus non-secure deployment is a design choice that lives at the deployment boundary, not a convenience flag you can safely ignore until the end. It affects how the service surface is exposed, how trust is exchanged between deployments, what topology options remain open, and whether later hardening is a small task or a controlled rebuild.
If the environment is meant to be durable, shared, or production-grade, start secure and make certificate management part of normal operations. If the environment is intentionally non-secure, keep it genuinely temporary, tightly bounded, and explicitly documented so the exception does not silently become the standard.
Test your understanding
Select an answer and click Check.
Q1 — In this article, which operational approach best matches "What the secure versus non-secure choice actually controls"?
Q2 — In this article, which operational approach best matches "Secure deployment, non-secure deployment, and reverse proxy are not interchangeable des..."?
Q3 — In this article, which operational approach best matches "Planning a secure deployment before you ever launch the assistant"?
Q4 — In this article, which operational approach best matches "Verification after a secure build should prove trust, not just process state"?
No comments:
Post a Comment