Ravindra BagaleCourses & study guides मराठी Track your progress

33. Cryptography Basics

33.5 Digital Signatures, Certificates, PKI and TLS

By Last updated:

Digital signature: hash the message, then encrypt the hash with your private key. Anyone verifies with your public key. If the message changes, the hash no longer matches. This gives integrity, authentication and non-repudiation.

openssl dgst -sha256 -sign private.pem -out msg.sig msg.txt
openssl dgst -sha256 -verify public.pem -signature msg.sig msg.txt     # Verified OK
echo "changed" >> msg.txt
openssl dgst -sha256 -verify public.pem -signature msg.sig msg.txt     # Verification failure

Certificates and PKI. How do you know a public key really belongs to reels.example.in? A Certificate Authority (CA) such as Let's Encrypt (Chapter 11) signs a certificate saying "this public key belongs to this domain". Browsers trust a list of root CAs; the chain goes root CA, intermediate CA, your certificate. This system is PKI (Public Key Infrastructure).

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
openssl req -x509 -newkey rsa:2048 -nodes -keyout lab.key -out lab.crt -days 30 -subj "/CN=lab.local"   # self-signed, lab only

How TLS (HTTPS) uses everything, in short:

  1. The browser connects and the server sends its certificate.
  2. The browser checks the CA signature, the domain name and the expiry date.
  3. Both sides use ECDHE to agree on a fresh shared secret (this gives forward secrecy).
  4. All data then flows encrypted with AES-GCM or ChaCha20, with integrity checks.

Use TLS 1.2 or 1.3 only; disable SSLv3, TLS 1.0 and 1.1. Tools such as sslscan, testssl.sh and nmap --script ssl-enum-ciphers check a server's configuration.

Ravindra Bagale's Tip

When the browser shows "Your connection is not private", students click "Advanced, Proceed". That's fine for a self-signed cert in your own lab, but never on a real bank or email site – it could be a man-in-the-middle attack (Chapter 24). Always check the lock icon and the domain name.

Lab

Sign a file and verify it, then change one character and verify again. Check the certificate of your own HTTPS site from Chapter 11 with openssl s_client and note the issuer and expiry date. Run nmap --script ssl-enum-ciphers -p 443 against your own server and list any weak protocols it reports.

Extended teaching notes

Why this lesson matters

Cryptography fails when people invent it. Use standard libraries, modern algorithms (AES-GCM, TLS 1.2+, bcrypt/argon2) and protect keys in a KMS or secrets manager.

Where crypto shows up

Where What to do
Passwords bcrypt/argon2/PBKDF2 via the framework hasher — never plain MD5/SHA1.
TLS Terminate on ALB/nginx with ACM/Let's Encrypt; redirect HTTP to HTTPS.
JWT / API tokens Short lifetime, rotate signing keys, store secrets outside Git.
Disk / S3 Provider or customer-managed keys; least privilege on decrypt.

Mini case study

Suppose we are on a purple-team exercise for an Indian mid-size company (sample data). Red notes a technique from this lesson against a lab clone. Blue must show the control that stops it, the log that would have fired, and the ticket that hardens production. That is the standard this course trains you for.

Defender's worksheet (do this today)

  1. Write the lesson title, date and the exact lab target you are allowed to use.
  2. List three owned systems (VMs, apps, or cloud accounts) where this lesson applies.
  3. Run one safe check from the lesson on a lab system only. Paste the command and output.
  4. Write a two-sentence fix you would give a teammate.
  5. Name one related public advisory (CERT-In, CISA, NVD, or a vendor bulletin) with its date.

Indian workplace (sample data)

Suppose we are a junior analyst at Infosys, TCS, Wipro or a fintech SOC in Bengaluru/Pune. Turn this lesson into one checklist item with an owner, a due date and a place to store evidence (ticket + screenshot).

Global practice

Compare your notes with OWASP, CIS Benchmarks, NIST CSF/IR guidance or a cloud Well-Architected security question. Write five lines on what overlaps.

Everyday analogy

Explain the risk and the fix to a family member without jargon. If they can repeat the warning, you understand it well enough to teach juniors.

Key terms

  • Control: a safeguard (patch, config, process, detection).
  • Finding: a weakness backed by evidence.
  • Remediation: the fix plus how you verified it.
  • Scope: systems you have written permission to touch.
  • Least privilege: only the access the task needs.
  • Defence in depth: several layers so one failure does not end the story.

Common mistakes

  • Skipping written permission "just for a quick scan".
  • Practising on hostel, office or public targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying attack steps onto production to "verify". Defenders verify with versions, configs and patches.
  • Publishing screenshots that contain secrets, cookies or internal hostnames.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Fix > spectacle.

Real incident: OVHcloud CLI – a hijacked GitHub account swapped release files and their checksum file to steal secrets (Oct 2026)

1. What happened

OVHcloud is a large French cloud and hosting company. It gives developers a free, open-source command-line tool (CLI) called ovhcloud-cli, so they can manage their servers and cloud services from a terminal. People download this tool from the Releases page of OVHcloud's GitHub project.

  • On 19 October 2026, between 14:47 and 16:21 Paris time (about 6:17 pm to 7:51 pm IST), an attacker used the hijacked GitHub account of an OVHcloud developer to replace the download files inside five old releases, v0.11.0 to v0.15.0.
  • The new files were a secret-stealing program. It looked like the normal tool, but it also copied secrets from the computer's disk: cloud logins for AWS, Google Cloud and Azure, SSH keys, Kubernetes, Docker, npm and Terraform settings, Git settings and the history files of AI coding assistants.
  • On the v0.15.0 release, the attacker also replaced the checksums.txt file, so the published hashes matched the bad files.
  • A customer's automatic build job failed because it compared the downloaded file with a SHA-256 hash it had saved earlier, and the hash no longer matched. The customer reported it on GitHub at 15:50 Paris time. OVHcloud removed the bad files at 16:21.
  • OVHcloud says the bad files were online for about 1 hour 33 minutes and were downloaded about 250 times. The source code and the build pipeline were not changed. Homebrew installs (which check a saved hash), go install and the Docker image were not affected.
  • The same evening, OVHcloud published a clean v0.16.0 with a signed tag as an immutable release (GitHub does not let anyone change its files). OVHcloud says the root problem was that release immutability was not turned on, and that the developer's keys were stolen months earlier, after a malicious code-editor extension was installed on the developer's personal laptop.

2. How the hack happened (public reporting only – high-level)

  1. Months earlier, a malicious extension for a code editor ran on the developer's personal laptop and stole keys for the developer's GitHub account.
  2. That account had write access to the OVHcloud CLI project on GitHub.
  3. On GitHub, anyone with write access can delete the files of an old release and upload new files with the same names, unless release immutability is on. The download link stays the same, so users see nothing unusual.
  4. The attacker built a copy of the tool with stealing code added, and uploaded it by hand. The company's normal build pipeline never ran.
  5. The attacker also uploaded a new checksums.txt. So a user who checked the download against the hash file on the same page got "OK" – the file and its proof were changed together.
  6. Anyone who installed or updated the tool in that window, with the install script, a manual download or a build job without a saved hash, ran the stealer. It collected secrets from the disk and sent them to the attacker.

3. How to stop it / defend (this lesson: digital signatures)

  • A hash only proves "this file matches that hash". If the hash sits on the same page as the file, an attacker who can change one can change both. It is like a shop where the thief can also change the price list.
  • Check a digital signature, not only a hash. In this lesson, the publisher signs with a private key and you verify with their public key. An attacker who changes the file cannot make a new valid signature without that private key, so openssl dgst -verify (or gpg --verify, cosign verify) shows a failure.
  • Save the expected hash before you need it. The customer's build job caught this attack because it pinned the SHA-256 of the tool. Pin versions and hashes in CI pipelines, Dockerfiles and install scripts.
  • If you publish software: turn on release immutability, sign tags and release files, publish build attestations, and let only the build pipeline (not a person's laptop) upload release files.
  • Protect developer accounts: MFA for every account, short-lived tokens, and install editor extensions only from known publishers. A developer laptop that holds publishing keys is a target.

4. How to take care so it won't happen again (checklist)

  • [ ] If you installed or updated ovhcloud-cli on 19 October 2026 in that window, treat every secret on that computer as stolen: change it from a different computer, delete the tool and install v0.16.0 or later.
  • [ ] For every tool you download, prefer a signature or attestation check over a hash on the same page.
  • [ ] Pin versions and SHA-256 hashes in your build jobs and install scripts.
  • [ ] Don't keep long-lived cloud keys in plain files on laptops; use short-lived logins and a secrets manager.
  • [ ] If you publish releases: immutable releases on, signed tags on, uploads only from the pipeline.
  • [ ] Review who has write access to your repositories every month, and remove old accounts.

Source: OVHcloud security advisory "ovhcloud-cli security incident - October 19th, 2026" on the project's GitHub page, 20 October 2026; BleepingComputer, "OVHcloud CLI releases backdoored on GitHub to steal developer secrets", 20 October 2026; The Hacker News, "Hackers Hijack Five OVHcloud CLI Releases to Distribute Secret-Stealing Malware", 20 October 2026.

Check if you're safe: Password Strength Checker

Real incident: eMudhra – eight Indian CA intermediate keys were made with weak randomness, so anyone could forge HTTPS certificates (Oct 2026)

1. What happened

eMudhra is an Indian Certificate Authority (CA). In this lesson you learnt that a CA signs certificates, and browsers trust the chain root CA → intermediate CA → website certificate. If an attacker gets an intermediate CA's private key, they can sign a "valid" certificate for any website.

  • On 17 October 2026, a security researcher reported to the browser makers that the private keys of eight eMudhra intermediate CAs were weak.
  • Google says the keys were made with insufficient randomness (weak entropy). So anyone could work out the private keys from the public certificates and forge trusted HTTPS certificates.
  • With a forged certificate, an attacker who sits in the middle of a connection could pretend to be a real website and read or change the traffic (a man-in-the-middle attack).
  • Chrome blocked the eight intermediates the same day, at 19:45 UTC on 17 October (about 1:15 am IST on 18 October), using its CRLSet block list, so users did not need a full browser update. Firefox finished its block by 22:59 UTC the same day.
  • eMudhra revoked all eight intermediates on 18 October. It says seven were never used in production, and the one in production had not issued a single certificate.
  • Google says no certificate from these CAs was logged in Certificate Transparency (CT) before the block. eMudhra says it knows of no misuse before the report.
  • As a safety step, Google and Mozilla are removing the root that signed them, emSign ECC Root CA - G3. Chrome's removal is expected on 27 October 2026. Websites with certificates under this root must get a new certificate from another CA now.
  • eMudhra says its eSign and digital signature services in India are not affected.

2. How the hack happened (public reporting only – high-level)

  1. On 30 April 2025, eMudhra ran a Key Generation Ceremony (a formal, audited meeting where CA keys are created) and made the eight intermediate keys inside certified hardware security modules (HSMs).
  2. eMudhra says one step, a key wrap/unwrap step, made a second, weak set of keys next to the strong ones.
  3. The weak keys were the ones that went into the certificates sent to the browser trust lists.
  4. The mistake stayed hidden for about 18 months and passed two independent audits.
  5. A researcher studied the public certificates and worked out the private keys, reportedly with help from AI tools. They reported it before any known attack.
  6. eMudhra has not yet confirmed the exact root cause.

3. How to stop it / defend (this lesson: certificates, PKI and TLS)

Why: a lock icon only means "a trusted CA signed this". If a CA key is weak, the lock can lie. So every program must use an up-to-date trust list and must never skip certificate checks.

Steps to follow now:

  1. Check your own websites. Run openssl s_client -connect yoursite.in:443 -servername yoursite.in </dev/null | openssl x509 -noout -issuer and look for emSign ECC Root CA - G3 in the chain. If you see it, get a new certificate from another CA before 27 October.
  2. Update browsers. Chrome and Firefox got the block by themselves. Android phones get the fix through Google Play Services.
  3. Update trust stores on servers, not just browsers. Many apps use their own list of trusted CAs.
  4. Rebuild containers from updated base images, then restart the apps so they load the new list.
  5. If you see new certificate errors after updating, fix the certificate. Never turn off verification (for example verify=False or curl -k).

How to refresh the trusted CA list in common stacks:

  • Ubuntu/Debian: sudo apt update && sudo apt install --only-upgrade ca-certificates
  • RHEL / Amazon Linux: sudo dnf update ca-certificates
  • Python (requests, httpx): pip install --upgrade certifi, or point the app at the system store.
  • Java / Spring: update the JDK, because its cacerts keystore holds the trusted roots; check any custom keystores too.
  • Node.js: update Node.js, because it ships its own CA list; check any custom NODE_EXTRA_CA_CERTS file.
  • .NET, Go, PHP (curl), nginx proxies: these usually read the operating system store, so update ca-certificates and restart the service.
  • Docker: rebuild the image on a fresh base image; an old image keeps the old list.

4. How to take care so it won't happen again (checklist)

  • [ ] Keep a list of every certificate you use and which CA and root it chains to.
  • [ ] Watch Certificate Transparency logs (for example search your domain on crt.sh) for certificates you did not ask for.
  • [ ] Add a DNS CAA record so only your chosen CA may issue for your domain, for example yoursite.in. CAA 0 issue "letsencrypt.org".
  • [ ] Update ca-certificates, language runtimes and base images every month, and restart services after.
  • [ ] Never ship code with certificate checks turned off, even "just for testing".
  • [ ] Use automatic, short-lived certificates (ACME), so changing CA in an emergency takes minutes.
  • [ ] Keep a second trusted CA ready, so one CA problem cannot stop your site.

Source: Google Chrome and Android Security Teams, "Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates", Google Blog, 20 October 2026; Mozilla Firefox Security Team, "Protecting Firefox users following the compromise of eMudhra intermediate certificates", Mozilla Security Blog, 20 October 2026 (updated 21 October 2026); eMudhra, "eMudhra Statement on Recent Certificate Security Incident", eMudhra official website, 20 October 2026 (updated 22 October 2026); Cloudflare, "8 eMudhra certificates are compromised. Here's what you need to know", Cloudflare Blog, 20 October 2026; Palo Alto Networks Unit 42, "eMudhra Intermediate CA Certificates Compromised", 22 October 2026.

Check if you're safe: Website Security Checklist