🛡️ Automating SSL Certificate Access and Distribution using Forms and Power Automate.

⏱ Estimated reading time: 5 minutes

• Automate SSL certificate requests and sharing within your organization.
• Uses Microsoft Forms, Power Automate, SharePoint Online, and Exchange Online.
• Includes email validation, approval, access assignment, and secure delivery.
• Designed for Microsoft 365, Middleware, DevOps, and Enterprise Support teams.

---

Table of Contents

• Introduction
• Business Challenge
• Solution Overview
• Power Automate Workflow Diagram
• Step 1: Certificate Request Form
• Step 2: Organizational Email Validation
• Step 3: Approval Workflow
• Step 4: Automated Certificate Distribution
• Step 5: SharePoint Access Assignment
• Security Design
• Key Takeaways

---

Introduction

Manual SSL certificate sharing often requires repeated emails, approvals, permission changes, and file transfers. This becomes difficult to manage when many applications and users are involved.

Using Microsoft Forms and Power Automate, the process can be standardized from request submission to approval, SharePoint access, and certificate delivery.

Key Concept:
Automation reduces manual effort while approval and access controls keep certificate sharing secure and auditable.

---

Business Challenge

The manual process introduced several operational and security challenges:

• Requester details were verified manually.
• Requests did not follow a standard format.
• Approvals and delivery required repeated follow-ups.
• Sensitive files could be shared through uncontrolled channels.
• Tracking request, approval, and delivery history was difficult.

---

Solution Overview

Microsoft Forms collects the request, Power Automate manages the workflow, SharePoint Online stores the certificate, and Outlook sends notifications.

Component	Purpose
Microsoft Forms	Captures certificate request details.
Power Automate	Manages validation, approval, access, and delivery.
Approval Connector	Sends the request to the Certificate Administrator.
SharePoint Online	Stores certificate files and manages reader access.
Exchange Online / Outlook	Sends certificate, private key, and rejection emails.

---

Power Automate Workflow Diagram

The flow validates the requester before approval. Approved requests receive the certificate and SharePoint access, while rejected or unauthorized requests are stopped.

F Microsoft Forms

When a New Response is Submitted Microsoft Forms Trigger

F Microsoft Forms

Get Response Details Retrieve Name, Email ID, Application Name

Condition 1

Validate Organization Email Domain

True

A Approvals

Start and Wait for an Approval Approval request sent to Certificate Administrator

Condition 2

Check Approval Outcome

True

O Office 365 Outlook

Send an Email (V2) 1 Certificate file and SharePoint path access

O Office 365 Outlook

Send an Email (V2) 2 Private key file

False

O Office 365 Outlook

Send an Email (V2) Request rejection notification

False

■ Control

Terminate Invalid or unauthorized email domain

Workflow Logic:
A valid corporate email proceeds to approval. Approved requests receive the certificate and private key through separate emails. Rejected or invalid requests do not receive access.

---

Step 1: Certificate Request Form

Users submit requests through Microsoft Forms. The form captures:

• Requester Name
• Email Address
• Application Name

Submitting the form automatically starts the Power Automate flow.

---

Step 2: Organizational Email Validation

Power Automate verifies that the requester belongs to an approved corporate domain.

endsWith(emailAddress,'@company.com')

Security Control:
Requests from non-approved email domains are terminated automatically.

---

Step 3: Approval Workflow

After validation, the Certificate Administrator receives an approval request containing:

• Requester Name
• Email Address
• Application Name
• Request Timestamp

The administrator selects Approve or Reject. No certificate or private key is sent until the request is approved.

---

Step 4: Automated Certificate Distribution

After approval, Power Automate sends two separate emails.

Email 1 – Certificate Delivery

Subject: Certificate Request Approved

Attachments:
certificate.crt
certificate.pem

Body:
Your certificate request has been approved.
SharePoint read access has been granted.

Email 2 – Private Key Delivery

Subject: Private Key File

Attachment:
privatekey.key

Body:
Please find the private key file attached.
This file is confidential and should be stored securely.

Security Best Practice:
Use encryption, password-protected files, restricted access, or secure vault-based storage for stronger protection.

---

Step 5: SharePoint Access Assignment

After approval, Power Automate grants Reader access to the relevant SharePoint library or folder and sends the repository link.

User Approved
      │
      ▼
Power Automate
      │
      ▼
Grant SharePoint Reader Access
      │
      ▼
Send Repository Link

This removes manual permission assignment and ensures access is granted only after approval.

---

Security Design

Control	Purpose
Email Domain Validation	Blocks external or unauthorized requests.
Approval Workflow	Ensures certificate sharing is authorized.
Separate Email Delivery	Reduces exposure of the certificate and private key together.
SharePoint Reader Access	Provides controlled repository access.
Power Automate Run History	Tracks each workflow execution.
Approval History	Records approval and rejection decisions.

Enterprise Recommendation:
Store certificate files and private keys in separate secured repositories and retain request, approval, and access logs.

---

Key Takeaways

• Microsoft Forms provides a standard request portal.
• Power Automate manages validation, approval, and delivery.
• SharePoint provides controlled certificate access.
• Certificate and private key files are delivered separately.
• The solution improves security, efficiency, and auditability.

---

Real-World Outcome:
A manual email-based activity becomes a secure, automated, and auditable SSL certificate sharing process.

---

Category: Microsoft 365 Automation, Power Automate, SharePoint Online, Enterprise Security, SSL Certificate
Author: Pradeep V
Blog: MiddlewareBox.com

---

🌐🧱 Enterprise Network Architecture — Akamai, DNS, WAF, DMZ, SSL & Firewall Flow Explained for Middleware & DevOps Engineers🔒🔑

• 🏢 In an enterprise environment, understanding how network traffic flows from users to internal applications is essential for performance, security, and compliance.
• 🌐 This post explains the complete inbound and outbound flow — covering DNS, Akamai WAF, Firewall, DMZ, and SSL certificate management across enterprise systems.

---

📑 Table of Contents

• 🗺️ Network Flow Diagram
• 🧰 Setup Phase (One-Time Configurations)
• 🌍 Where the Public IP Is Mapped
• 🌐 How CDN & DNS Flow Works
• 🏠 Where the Private IP Is Mapped (DNAT & SNAT)
• ⚙️ Runtime Flow (When Users Access the App)
• Inbound Flow (Internet → App)
• Outbound Flow (Internal App → Internet)
• 🔠 Key Terms (Full Forms)
• ✅ Summary

---

🗺️ Network Flow Diagram

🔹 Inbound Flow (User → Application → Database):
🌐 User → 🧭 Akamai DNS → 🛡️ Akamai WAF → 🚧 Firewall → 🏰 DMZ → 📡 Load Balancer → 🖥️ Web Server → ⚙️ App Server → 💾 Database

🔹 Outbound Flow (Internal App → Internet):
🖥️ VM/App → 🧭 Internal DNS → 🛡️ Proxy Server → 🚪 Firewall (SNAT) → 🌍 Internet

---

🧰 Setup Phase (One-Time Configurations)

• 🧭 DNS (Domain Name System): Resolves domain names into IP addresses for user access.
• 📄 A Record: Maps a domain name to an IP address (e.g., app.company.com → 104.85.32.11).
• ✅ DNS Validation: Verifies domain ownership during SSL or CDN setup using a TXT record.
• 🔒 SSL Certificate Setup: Enables secure HTTPS communication between users and servers.
• 🌍 Public SSL (Internet Apps): Managed by Akamai CPS, DigiCert, or Let’s Encrypt.
• 🏢 Internal SSL (Intranet Apps): Used for applications accessed inside an organization’s private network — typically using Microsoft ADCS or HashiCorp Vault PKI for certificate management. Additionally, internal SSL certificates are often deployed directly on web servers such as:
  • 🌐 Apache HTTP Server — configured in ssl.conf or virtual host files.
  • ⚙️ NGINX — defined using ssl_certificate and ssl_certificate_key directives.
  • 🪟 Microsoft IIS — managed via IIS Manager or PowerShell scripts.
  • 🖥️ IBM IHS or F5 / Radware — for SSL termination or offloading at the load balancer level.
• 🛡️ Firewall & DMZ Setup: Protects internal systems from public exposure.

---

🌐 How CDN & DNS Flow Works

Let’s simplify what happens when someone accesses https://app.company.com and you’re using a CDN like Akamai:

1. 🧭 DNS resolution (First Step)
   app.company.com → app.company.com.edgesuite.net # The domain is not directly mapped to your firewall. Instead, it's pointed to Akamai’s CDN hostname (CNAME). This lets Akamai handle global routing, SSL, and caching before hitting your network.
2. 🌍 Akamai Edge IP resolution
   app.company.com.edgesuite.net → 104.85.32.11 # Akamai DNS picks the nearest edge server IP based on user location. This gives low latency and faster content delivery (geo-DNS routing).
3. 🛡️ User connects to Akamai Edge
   Akamai Edge performs:
   - WAF (Web Application Firewall) checks
   - SSL/TLS termination
   - Content caching for faster response
   - Origin fetch (only if needed) # The user’s browser never touches your firewall directly. Akamai acts as the “front door” — securing, filtering, and caching content. This is where DDoS protection and certificate validation happen.
4. 🏰 CDN connects to your enterprise public IP
   Akamai Edge → 203.122.10.55 # Akamai now makes a backend (origin) call to your organization’s public IP. This IP is provided by your ISP and configured on your enterprise firewall as a VIP (Virtual IP). It represents your app’s public presence on the Internet.
5. 🚧 Firewall DNAT Mapping (Public → Private)
   203.122.10.55 → 10.10.5.21 # The firewall receives the request on the public IP and uses DNAT (Destination NAT) to map it to the private IP of your internal web/app server. This keeps internal servers hidden while maintaining full access control.
6. 🖥️ Private App Server Processing
   The request reaches 10.10.5.21 → app logic executes → response generated. # This is where your actual business logic runs (Tomcat, WebSphere, NGINX, etc.). The app prepares a response that travels back the same path — but in reverse.
7. 🔁 Response Path (Reverse Flow)
   App Server → Firewall SNAT → Akamai Edge → User Browser # The firewall uses SNAT (Source NAT) to mask internal IPs with the public IP. Akamai then caches or delivers the content to the user securely.

🧑‍💻 User Browser
   ↓
🧭 DNS → 🌐 app.company.com → 🌀 app.company.com.edgesuite.net
   ↓
🌍 Akamai Edge IP (104.85.32.11)
   ↓
🛡️ Akamai Edge → 🚧 Firewall Public IP (203.122.10.55)
   ↓
🏢 Firewall DNAT → 🖥️ Internal DMZ / Web / App Server (10.10.5.21)
   ↓
🔁 Response → 🚪 Firewall SNAT → 🌍 Akamai Edge → 🧑‍💻 User

💬 In short:

• 👥 Users never connect directly to your private network.
• 🛡️ Requests first hit Akamai’s Edge IPs — acting as a secure global shield for your applications.
• 🌍 Akamai forwards clean traffic to your enterprise Public IP (assigned by ISP).
• 🚧 The Firewall performs DNAT to map the public IP to a Private App Server (10.x.x.x).
• 🔁 During the return flow, the Firewall uses SNAT to mask internal IPs before sending responses back to the user.

---

⚙️ Runtime Flow (When Users Access the App)

Inbound Flow (Internet → App)

• 🌍 User opens https://app.company.com
• 🧭 DNS resolves to Akamai Edge IP.
• 🛡️ Akamai WAF filters and forwards clean traffic.
• 🚧 Firewall performs DNAT to internal private IP.
• 🏰 DMZ hosts load balancer/web proxies.
• 📡 Load balancer distributes traffic to web/app servers.
• 🖥️ App processes request and sends response back through the same path.

---

🔠 Key Terms (Full Forms)

Term	Full Form	Simple Meaning
DNS	Domain Name System	Converts website names into IPs
WAF	Web Application Firewall	Blocks bad web traffic
CDN	Content Delivery Network	Delivers cached web content faster
DMZ	Demilitarized Zone	Buffer zone between internet & private network
NAT	Network Address Translation	Maps public ↔ private IPs
DNAT	Destination NAT	Inbound mapping (public → private)
SNAT	Source NAT	Outbound mapping (private → public)
PKI	Public Key Infrastructure	Manages SSL certificates
LB	Load Balancer	Distributes traffic across servers

---

✅ Summary

• DNS only maps names to IPs — it doesn’t store servers.
• CDNs like Akamai act as a smart middle layer for caching and security.
• Public IPs are used on firewalls or load balancers; private IPs stay hidden inside.
• DNAT and SNAT handle IP translation for inbound and outbound traffic.
• SSL ensures secure HTTPS connections both at the CDN and internal layers.

---

🔧 Authored by Pradeep Vishwakarma — Senior Middleware & DevOps Engineer | MiddlewareBox.com