12.9.2. Quick Ref Guide: OKI, SSL/TLS & Certificates

PKI, SSL/TLS & Certificates – Quick Reference for Techs

Use this as a fast refresher on PKI concepts, X.509 certificates, common file types and rollout steps for public, internal, MikroTik and self-signed certificate deployments.

1. Core Concepts

Term What it is Where used / Why it matters
PKI (Public Key Infrastructure) System of CAs, certificates, keys and policies that issues and manages X.509 certificates. Used to provide identity, encryption and integrity for users, devices and services (websites, VPNs, Wi-Fi, code signing, etc.).
SSL/TLS The protocol used to secure traffic between client and server (HTTPS, SMTPS, LDAPS, etc.). Uses certificates to authenticate the server (and optionally the client) and negotiate session keys for encrypted traffic.
CA (Certificate Authority) Trusted entity that signs certificates. Can be a public CA (e.g. DigiCert/Let’s Encrypt) or an internal Enterprise CA (including MikroTik RouterOS in small deployments). If the client trusts the CA, it trusts certificates issued by that CA.
Root CA / Intermediate CA Root is top-level, self-signed. Intermediate CAs are signed by the root, and actually issue end-entity certs. Chains reduce risk: the root stays offline, intermediates do day-to-day issuing. Clients must see a valid certificate chain.
CRL & OCSP CRL = Certificate Revocation List (downloadable list).
OCSP = Online Certificate Status Protocol (real-time status check). 		Used so clients can check if a cert is revoked (compromised keys, wrong issuance, etc.).
Key Pair Private key (kept secret) + public key (embedded in cert). Private key signs / decrypts; public key verifies signatures / encrypts to the owner. Loss of the private key = reissue/replace cert.

2. X.509 Certificate – What’s Inside

Key Fields
  • Subject – who the cert is for (CN, organisation, etc.).
  • Issuer – CA that signed it.
  • Validity – Not Before / Not After dates.
  • Public Key – RSA / EC public key.
  • Serial Number – unique per issuing CA.
Extensions
  • Key Usage – e.g. Digital Signature, Key Encipherment.
  • Extended Key Usage – e.g. Server Auth, Client Auth, Code Signing.
  • Subject Alt Name (SAN) – DNS names, IPs, UPNs.
  • CRL/OCSP URLs – where to check revocation.
Remember: Browsers and OSs validate the chain (end-entity → intermediate → root), check expiry, key usage, SANs, and revocation. Most “certificate errors” = one of these failing.

3. Common Certificate & Key File Types

Extension Contains Encoding Typical Use
.key Private key only (RSA or EC). PEM or DER. Often PKCS#1 / PKCS#8. Used by web servers, VPNs, proxies, MikroTik RouterOS, etc. Must be kept strictly private.
.crt / .cer Certificate (public key + metadata). PEM (Base64) or DER (binary). Installed on servers or clients to present / trust certificates.
.pem “Container” – may hold certs, keys, or chains (Base64 with -----BEGIN ...-----). PEM (Base64 + header/footer). Common on Linux/OpenSSL, MikroTik, load balancers.
.pfx / .p12 PKCS#12 bundle – private key + cert + chain, usually password-protected. Binary. Used on Windows / browsers / IIS / appliances for import/export.
.csr Certificate Signing Request – contains subject, SANs, public key, etc. PEM or DER. Generated by server; sent to CA to request a certificate.
.der Cert (or key) in binary DER encoding. DER. Used by some network devices / Java keystores.
Copying PEM Certificates & Keys

When working with PEM files (.pem, .crt, .key, .csr), always copy the entire block, including the -----BEGIN ...----- and -----END ...----- lines. 

——-BEGIN CERTIFICATE——-
MIIFwDCCA6igAwIBAgISA3h3N1Zp0k3B…
… more base64 lines …
ABC123==
——-END CERTIFICATE——-
  • Do copy from the first - of -----BEGIN to the last - of -----END, inclusive.
  • Do keep all base64 lines in order; line breaks are fine, but don’t add spaces/tabs inside lines.
  • Don’t strip the header/footer – many tools (OpenSSL, MikroTik, web servers) require them to recognise PEM format.
  • Some UIs use single-line fields but still accept normal line breaks – paste the whole block as-is.

4. Common Deployment Patterns & Rollout Steps

4.1 Public CA – Internet-facing Websites / Services (e.g. Let’s Encrypt or Commercial CA)
  1. Plan names & endpoints: Decide which hostnames (FQDNs) need certs – e.g. portal.example.com, vpn.example.com.
  2. Choose CA & method: ACME (Let’s Encrypt/ZeroSSL), or commercial CA (DigiCert, Sectigo, etc.).
  3. Prove domain control:
    • ACME HTTP-01 (file on web server) or DNS-01 (TXT record); or
    • CA portal using email/DNS/HTTP validation.
  4. Generate key + CSR: On the server, load balancer, or via OpenSSL / IIS / certmgr tools.
  5. Request certificate: Submit CSR to CA or let ACME client handle automatically.
  6. Install certificate: Import cert + intermediate chain and bind to HTTPS / VPN / SMTP/IMAP etc.
  7. Verify: Test via browser/SSL checker – check chain, hostname, expiry, protocols/ciphers.
  8. Automate renewals: ACME client (e.g. certbot, win-acme) or CA API + scripts / scheduled tasks.
4.2 Internal PKI – Enterprise CA (e.g. Microsoft AD CS)
  1. Design the hierarchy: At minimum have an offline Root CA and one or more online Issuing CAs.
  2. Build the Root CA: Standalone server (often offline/VM snapshot), create root cert, configure CRL/OCSP URLs.
  3. Build Issuing CA(s):
    • Install AD CS Enterprise CA on domain-joined server.
    • Enroll Issuing CA cert from Root, import and start service.
  4. Publish trust & CRLs:
    • Distribute Root CA cert via Group Policy (Trusted Root store).
    • Ensure CRL/OCSP URLs reachable (HTTP share / OCSP responder).
  5. Create templates: Web Server, Client Auth, Computer, RDS, VPN, Wi-Fi, Code Signing, etc. Define key size, validity, EKU.
  6. Auto-enrollment (AD): Use GPO to automatically issue certs to computers/users based on templates.
  7. Integrate with services: Configure IIS, RDS, LDAPS, VPN, Wi-Fi (802.1X), etc. to use internal certs.
  8. Operations: Monitor CA, CRLs, expiries; have a documented process for revocation and renewal.
4.3 Self-Signed Certificates – Lab / Device / One-off Use

Self-signed = cert is signed by its own key. Only safe when you directly control both clients and servers, and you manually distribute trust.

  1. Generate key + self-signed cert: e.g. via OpenSSL, PowerShell, device UI (MikroTik, router, NAS, etc.).
  2. Export cert (no private key): Usually as .cer/.crt/.pem.
  3. Distribute trust: Import into Trusted Root on all required clients / devices.
  4. Bind cert: Configure the service (HTTPS/VPN/API) to use this key/cert pair.
  5. Plan rotation: Track expiry manually and regenerate / redeploy before it expires.

Do not use self-signed certs for public websites. Browsers will always show a warning unless you import the cert as a trusted root.

4.4 Mutual TLS (mTLS) – Client + Server Certificates
  1. Issue server certs: From public or internal CA, as normal HTTPS/VPN certs.
  2. Issue client certs: From same or dedicated Client Auth CA/template.
  3. Distribute client certs + private keys: As .pfx to devices/users (MDM, GPO, manual import).
  4. Enable client cert auth: On server/load balancer, require client certificate and trust the issuing CA.
  5. Map identities: Use subject/SAN to map to users/devices (e.g. UPN, CN, serial).
4.5 MikroTik RouterOS – Acting as a CA & Issuing Certificates (PEM / KEY / PEM Bundles)

RouterOS includes a basic certificate manager and can act as a small CA. It can generate its own CA certificate, create and sign server/client certificates, and export them as PEM and KEY files for use on other devices (or import existing PEM/PFX from an external CA).

  1. Create a CA on the MikroTik
    • CLI: /certificate add name=MyCA common-name=MyCA key-size=4096 key-usage=key-cert-sign,crl-sign
    • Then self-sign: /certificate sign MyCA ca-crl-host=<router-ip-or-fqdn>
    • This creates a Root CA on the router with its own private key.
  2. Create server / client certificates
    • Example server cert:
      /certificate add name=server-cert common-name=vpn.example.local key-size=2048 key-usage=digital-signature,key-encipherment,tls-server
    • Example client cert template:
      /certificate add name=client-cert common-name=user1 key-size=2048 key-usage=digital-signature,key-encipherment,tls-client
    • Sign them with your MikroTik CA:
      /certificate sign server-cert ca=MyCA
      /certificate sign client-cert ca=MyCA
  3. Export CA and certificates (PEM / KEY files)
    • Export CA certificate only (for trust on clients):
      /certificate export-certificate MyCA export-passphrase=""
      Produces a .crt (PEM) file that can be imported into OS/browser/NAS as a trusted root.
    • Export server or client cert + private key:
      /certificate export-certificate server-cert export-passphrase=StrongPass!
      This yields a .crt and .key PEM pair you can upload to web servers, VPN appliances, or other MikroTik routers.
    • You can also export in PKCS#12 (.p12) on newer RouterOS:
      /certificate export-certificate server-cert type=pkcs12 export-passphrase=StrongPass!
  4. Use certificates on the MikroTik itself
    • HTTPS / WebFig:
      Set the web server certificate: /ip service set www-ssl certificate=server-cert and enable HTTPS.
    • IPSec / IKEv2 / SSTP / OpenVPN:
      Reference server-cert in the VPN profile / peer (for server side) and client-cert in the client profile on other routers.
  5. Rollout steps for a “MikroTik mini-PKI”
    • 1. Create & sign a CA on a “master” MikroTik.
    • 2. Export the CA cert (.crt) and import it as a trusted Root on admin PCs, servers, and other MikroTik routers.
    • 3. Generate & sign server/client certs for VPN, HTTPS, CAPsMAN, etc.
    • 4. Export PEM/KEY or P12 and deploy them to endpoints (other routers, servers, VPN concentrators).
    • 5. Bind certificates to services (e.g. IPSec, SSTP, WebFig, API-SSL).
    • 6. Document expiry dates and create a simple calendar / script to renew and re-export before expiry.

For small environments or lab setups, this MikroTik-based CA is quick and easy. For larger, multi-site or compliance-heavy environments, prefer a dedicated PKI (e.g. AD CS or external CA) and only import issued PEM/KEY or PFX files into RouterOS.

5. Quick Troubleshooting Cheats

Symptom Likely Cause What to Check
Browser says “Not secure” or “Unknown issuer”. CA not trusted or chain incomplete. Is Root/Intermediate installed? Is full chain presented?
Name mismatch / “Common Name invalid”. SAN does not contain requested hostname. Check SAN list; reissue cert with correct DNS names.
Service won’t start with cert. Private key missing, wrong format, or permissions issue. Ensure private key is present, key length supported, service account has access.
Clients report revoked/invalid cert. CRL/OCSP check failing or cert actually revoked. Check CRL/OCSP URLs, network access, and CA revocation status.



MikroTik RouterOS – Certificate Cheat Sheet (WinBox / WebFig)

Quick “click-path” guide for creating and using certificates on MikroTik RouterOS. Assumes RouterOS v6/v7 with the System → Certificates menu available.

A. Create a CA Certificate on MikroTik
  1. Open WinBox / WebFig and connect to the router.
  2. Go to System → Certificates.
  3. Click + (Add) to create a new certificate.
  4. In the General tab:
    • Name: e.g. MyCA
    • Common Name: e.g. MyLab-RootCA
    • Set Key Size (e.g. 4096) and Days Valid (e.g. 3650).
  5. In the Key Usage / Extensions tab:
    • Tick at least: key cert. sign, crl sign.
  6. Click OK – the cert appears with status “K” (has Key, not yet signed).
  7. Select the new MyCA cert and click Sign:
    • Leave CA field blank (self-signed).
    • Set Digest to e.g. sha256.
    • Click Start.
  8. After a few seconds, refresh – it should show KS (Key + Signed) and act as your Root CA.
B. Create & Sign Server / Client Certificates
  1. Still in System → Certificates, click + (Add).
  2. On General tab for a server cert:
    • Name: e.g. server-cert
    • Common Name: e.g. vpn.example.local
    • Optionally set Subject Alt Name for extra DNS names (in newer RouterOS).
  3. On Key Usage / Extensions tab:
    • For server: tick digital signature, key encipherment, tls server.
    • For client: tick digital signature, key encipherment, tls client.
  4. Click OK – cert appears with status K.
  5. Select the new cert (e.g. server-cert) and click Sign:
    • CA: choose MyCA (the CA created in step A).
    • Click Start.
  6. Once status shows KS, it’s a valid signed certificate.
C. Export CA & Certs as PEM / KEY
  1. In System → Certificates, select MyCA.
  2. Click Export:
    • For CA cert only: set Export Passphrase blank (or simple), untick “Export Key” (if shown).
    • This creates a .crt PEM file – download via Files and import as a trusted root on PCs/servers.
  3. For a server/client cert:
    • Select e.g. server-cert → Export.
    • Set a strong Export Passphrase to protect the private key.
    • RouterOS creates a .crt and a .key (PEM) file in Files.
    • Download and use these on other routers / servers / VPN appliances.
  4. On newer RouterOS, you can choose Type: PKCS12 to export a .p12 bundle compatible with Windows / browsers.
D. Bind Certificates to RouterOS Services
Service Where to Set Notes
HTTPS / WebFig IP → Services → www-ssl (or www-ssl tab)
Set Certificate = server-cert, enable HTTPS. 		Optionally disable www (HTTP) to force HTTPS.
SSTP Server PPP → SSTP Server
Set Certificate = server-cert. 		Clients must trust MyCA or use a public CA cert.
OpenVPN Server PPP → Interface → OVPN Server
Choose Certificate = server-cert. 		Use client-cert for client-side TLS auth (if configured).
IPSec / IKEv2 IP → IPSec
In the Profiles / Identities, set the Certificate for the peer. 		Common Name and SANs must match the hostname used by the client.
API-SSL / WinBox over TLS IP → Services → api-ssl
Set Certificate = server-cert. 		Use when exposing API to automation tools securely.
Optional – Quick CLI Reference 
    
	
  1. Create CA
    
/certificate add name=MyCA common-name=MyLab-RootCA key-usage=key-cert-sign,crl-sign
    
/certificate sign MyCA ca-crl-host=10.0.0.1
    2. 




    
	
  1. Create server cert
    
/certificate add name=server-cert common-name=vpn.example.local \
    key-usage=digital-signature,key-encipherment,tls-server
    
/certificate sign server-cert ca=MyCA
    2. 




    
	
  1. Export CA and server cert (PEM + KEY)
    
/certificate export-certificate MyCA export-passphrase=”“
    
/certificate export-certificate server-cert export-passphrase=StrongPass!
    2. 




    
	
  1. Bind to HTTPS
    
/ip service set www-ssl certificate=server-cert disabled=no
    
/ip service set www disabled=yes
    

  




            
              
              

      
      

      
            
              

                      

              Need more help with this?

              
                © 2021–2025 XSTRA Group Pty Ltd (Australia). All rights reserved.              
            

          
          
          

          

             Thanks for your feedback.