Inventiv.org
  • Home
  • About
  • Resources
    • USPTO Pro Bono Program
    • Patent Guide
    • Press Release
  • Patent FAQs
    • IP Basics
    • Patent Basics
      • Patent Basics
      • Set up an Account with the USPTO
      • Need for a Patent Attorney or Agent
    • Provisional Patent Application
      • Provisional Patent Application
      • Provisional Builder
      • After you submit a PPA
    • Utility Patent Application
      • Utility Patent Application
      • File a Utility Patent Application
      • What Happens After Filing Utility Application?
    • Respond to Office Actions
    • Patent Issurance
  • ProvisionalBuilder
  • Login
  • Contact
  • Blogs
Inventiv.org
  • Home
  • About
  • Resources
    • USPTO Pro Bono Program
    • Patent Guide
    • Press Release
  • Patent FAQs
    • IP Basics
    • Patent Basics
      • Patent Basics
      • Set up an Account with the USPTO
      • Need for a Patent Attorney or Agent
    • Provisional Patent Application
      • Provisional Patent Application
      • Provisional Builder
      • After you submit a PPA
    • Utility Patent Application
      • Utility Patent Application
      • File a Utility Patent Application
      • What Happens After Filing Utility Application?
    • Respond to Office Actions
    • Patent Issurance
  • ProvisionalBuilder
  • Login
  • Contact
  • Blogs

Enhancing Online Security: Restricting Untrusted Certificate Authorities to Prevent Data Breaches

Inventiv.org
November 26, 2025
Software

Invented by Perlman; Radia J., Kaufman; Charles W.

Most of us use the internet every day, clicking on websites, sending emails, and downloading apps. In the background, computers and servers are constantly checking if the places we visit are real and safe. They do this with digital certificates, which are like special ID cards for websites and software. But, what if someone with a fake or stolen ID sneaks past these checks? This is a real problem today. A new patent application presents a simple but powerful way to fix this, by putting tighter controls on who can give out these digital IDs for each site. Let’s explore how this works and why it matters.

Your browser does not support the video tag.

Background and Market Context

To understand why this invention matters, let’s look at how things work today. When you visit a website like your bank or a popular store, your browser checks if that website has a digital certificate. This certificate is sort of like an official badge, showing that the site is who it says it is. But who gives out these badges? That job belongs to companies called certificate authorities, or CAs. Your browser comes with a list of hundreds of CAs it trusts. If a website’s certificate was signed by any one of these CAs, the browser lets you in.

While this sounds good in theory, there’s a weak spot. If just one of the hundreds of CAs on your browser’s list is tricked, hacked, or acts badly, that CA can create a fake badge for any website. So, an attacker could pretend to be your bank, your email provider, or any site you trust. This isn’t just a made-up problem—there have been real cases where this has happened. When a CA is compromised, it puts everyone at risk, because browsers trust certificates from all CAs equally.

This is especially risky for big companies, banks, or organizations that need extra security. They might prefer only to trust a few select CAs for their own websites, not all the hundreds in the default list. But, right now, the system doesn’t make that easy. If a CA is in the list, it can sign certificates for any website, whether it has any connection to that website or not.

The market for online trust is huge and growing. More people are working from home, shopping online, and sending private messages than ever before. All of this relies on certificates for secure connections. As the stakes grow, so does the need for better, more fine-grained control over which CAs can vouch for which websites. That’s where this patent comes in. It proposes a way for browsers and other software to use not just a big master list of CAs, but also a special database that limits which CAs can be used for each website or service.

In short, this invention is aimed at making the internet safer for everyone, from ordinary people to big organizations, by stopping untrusted or rogue certificate authorities from putting us all at risk.

Scientific Rationale and Prior Art

The internet’s trust system is built on something called public key infrastructure, or PKI. In simple words, PKI is the system that lets computers know who to trust online. At its heart is the digital certificate, which proves that a website or email sender really is who they say they are. This certificate is signed by a CA, and your browser checks if the CA is on its list of trusted authorities.

Over the years, the main way to manage this has been with a single, flat list of trusted CAs. If a CA is in the list, it’s trusted to sign certificates for any website or service. The problem is, this list is long and hard to control. Organizations can remove or add CAs, but that’s about it. There are no built-in ways to say, “Only trust CA-A for mybank.com, but not for other sites,” or “Don’t trust CA-B for anything except this set of company servers.” There’s no easy way to have rules that are different for each website or service.

Some workarounds have been tried. For example, certificate pinning is a method where a browser remembers which CA signed a website’s certificate the first time, and expects to see the same CA in the future. But this has problems if the website changes its CA, or if there’s a mistake, causing users to be locked out. Certificate Transparency logs make it easier to spot fake certificates after the fact, but don’t stop them from being used in the first place.

Other solutions have involved removing CAs from the trusted list if they are caught misbehaving, but this is slow, and doesn’t help if the attack happens before the CA is discovered. Some browsers and organizations have tried to keep their own private lists of trusted CAs, but that’s hard to maintain, and it’s still an all-or-nothing approach.

The security community has long known that the weakest link in the trust chain is the large number of CAs, many of which are unknown to users or even to system administrators. One bad CA can break trust for everyone. There has never been a simple, flexible, and scalable way to say, “For this site, only trust these CAs,” or “For this email server, only accept certificates from these authorities.” That is the gap this patent addresses.

By introducing a new idea—a limiting database that matches specific websites or targets with their allowed CAs—the invention creates a way to have rules that are different for each site or service. This is something the old, flat-list model can’t do. The new system can work alongside the existing list, adding a powerful layer of control without breaking compatibility with the old system. It is a simple change, but one with big security benefits.

Invention Description and Key Innovations

Now, let’s look at how this new system actually works. The main idea is to use not just a single list of trusted certificate authorities, but also a “limiting database.” This database acts like a map, showing which CAs are trusted for each target, such as a website, a mail server, or even software that needs to be signed.

Here’s how it plays out in practice. Your browser or application still has its big list of trusted CAs, just like before. But now, it also checks the limiting database when it connects to a target. If the target—say, your bank’s website—is listed in the limiting database, the browser will only trust certificates for that site if they are signed by the CAs listed there. If a certificate comes from a CA that isn’t on the per-site list, even if it’s in the big master list, the browser won’t trust it.

If the site you visit isn’t listed in the limiting database, the browser falls back to the old way, using the big list of CAs. This means that the new system is flexible. It doesn’t require every website in the world to have a special rule. Only the most important or sensitive sites need to be listed in the limiting database.

Let’s say your company wants to make sure only certain CAs can issue certificates for its main website and its employee email servers. With the limiting database, the IT team can add these sites to the database along with the allowed CAs. If an attacker tries to trick your browser with a certificate from a rogue CA, the browser checks the limiting database, sees that the CA isn’t authorized for your company’s site, and refuses the connection. This blocks attacks that would otherwise slip through.

The limiting database can be set up in different ways. It can be downloaded from a trusted server, or kept up to date by your company’s IT department. It can use wildcards, so one rule can cover many related sites, like “*.example.com.” It can even use groups, to make managing large numbers of sites easier. The database can also be stored and retrieved in different ways, so it works for computers, phones, or cloud servers.

The new system is also smart about what to do when there are conflicts or missing information. If a site isn’t in the limiting database, the browser can just use its regular list. If a site matches more than one rule, there can be policies to pick the best match or warn the user. If a certificate is from a CA that’s in the limiting database but not in the regular list, policies decide what to do—maybe block the connection or show a warning.

What makes this invention stand out is its flexibility and simplicity. It doesn’t throw away the old way of doing things, but adds a powerful option for those who need more security. It lets organizations, app makers, or even regular users have much more control over who can vouch for each site or service. This means fewer chances for rogue or untrusted CAs to sneak in and cause trouble.

The patent also covers how to use this system with different kinds of applications, not just web browsers. It can work for signed email, software downloads, or any system that uses digital certificates. It can be built into hardware, software, or a mix of both. The instructions for checking the limiting database can be stored on any kind of computer storage, from hard drives to cloud servers.

In summary, this invention adds a layer of smart, targeted control to digital trust on the internet. It gives organizations and users the power to decide, for each website or service, which certificate authorities are allowed. This closes one of the biggest holes in the old system and makes online life safer for everyone.

Conclusion

Trust is the foundation of the internet, but the old way of trusting hundreds of certificate authorities equally is no longer enough. The new patent application introduces a simple but transformative idea: a limiting database that ties each website or service to its trusted certificate authorities. This gives users, companies, and software makers the power to decide who can vouch for their digital identity, closing a huge security gap. The invention works with existing systems, scales to any size organization, and adapts to the needs of today’s online world. By putting tighter controls on digital certificates, it makes the internet safer for all of us—one connection at a time.

Click here https://ppubs.uspto.gov/pubwebapp/ and search 20250219850.

Tags: Microsoft Patent Review
Previous Story
AI-Driven Platform Automatically Builds Custom APIs to Streamline Business Integration and Performance
Next Story
Effortless Multi-Platform Login: Secure Single Sign-On Solution for Diverse Enterprise Systems

Related Articles

AI Tool Translates Natural Language into Automated App Commands for Seamless User Interface Control

Invented by Shaw; Peter Thomas, Joshi; Mandar, Toutanova; Kristina Nikolova,...

Effortless Multi-Platform Login: Secure Single Sign-On Solution for Diverse Enterprise Systems

Invented by Awasthi; Brijendra, Bernert; Deborah, Frey; Heather, Otten; Chris,...

Menu

  • Home
  • About
  • Resources
    • USPTO Pro Bono Program
    • Patent Guide
    • Press Release
  • Patent FAQs
    • IP Basics
    • Patent Basics
      • Patent Basics
      • Set up an Account with the USPTO
      • Need for a Patent Attorney or Agent
    • Provisional Patent Application
      • Provisional Patent Application
      • Provisional Builder
      • After you submit a PPA
    • Utility Patent Application
      • Utility Patent Application
      • File a Utility Patent Application
      • What Happens After Filing Utility Application?
    • Respond to Office Actions
    • Patent Issurance
  • ProvisionalBuilder
  • Login
  • Contact
  • Blogs

Disclaimer Communications between you and Inventiv Foundation are protected by our Privacy Policy but not by the attorney-client privilege or as work product. Inventiv Foundation, Inc. can connect you to independent attorneys and self-help services at your specific direction. We are not a law firm or a substitute for an attorney or law firm. We cannot provide any kind of advice, explanation, opinion, or recommendation about possible legal rights, remedies, defenses, options, selection of forms or strategies. Your access to the website is subject to our Terms of Use.

Tags

Alphabet Amazon Facebook/Meta Microsoft Patent Review Samsung
  • Home
  • About
  • Inventiv’s Daily
  • Inventiv Cloud
  • Blogs
  • Contact
Inventiv.org
  • Home
  • About
  • Resources
    • USPTO Pro Bono Program
    • Patent Guide
    • Press Release
  • Patent FAQs
    • IP Basics
    • Patent Basics
      • Patent Basics
      • Set up an Account with the USPTO
      • Need for a Patent Attorney or Agent
    • Provisional Patent Application
      • Provisional Patent Application
      • Provisional Builder
      • After you submit a PPA
    • Utility Patent Application
      • Utility Patent Application
      • File a Utility Patent Application
      • What Happens After Filing Utility Application?
    • Respond to Office Actions
    • Patent Issurance
  • ProvisionalBuilder
  • Login
  • Contact
  • Blogs
Inventiv.org
  • Home
  • About
  • Resources
    • USPTO Pro Bono Program
    • Patent Guide
    • Press Release
  • Patent FAQs
    • IP Basics
    • Patent Basics
      • Patent Basics
      • Set up an Account with the USPTO
      • Need for a Patent Attorney or Agent
    • Provisional Patent Application
      • Provisional Patent Application
      • Provisional Builder
      • After you submit a PPA
    • Utility Patent Application
      • Utility Patent Application
      • File a Utility Patent Application
      • What Happens After Filing Utility Application?
    • Respond to Office Actions
    • Patent Issurance
  • ProvisionalBuilder
  • Login
  • Contact
  • Blogs