TL;DR

  • Qihoo 360 (China's largest cybersecurity firm, 461M users) bundled the SSL private key for *.myclaw.360.cn inside their "360 Security Claw" installer package — leaked on launch day [1]
  • Anyone who downloaded the installer gained access to a wildcard TLS certificate valid until April 2027, enabling man-in-the-middle attacks and phishing with legitimate HTTPS padlocks [2]
  • The irony: founder Zhou Hongyi promised "never leaks passwords" just days before shipping a private key in a .7z archive within the publicly distributed installer [3]
  • The certificate was issued by WoTrus CA (formerly WoSign, removed from browser trust stores in 2017 for misissuance), compounding trust concerns [4]

What Happened: Qihoo 360's SSL Private Key Leak Explained

On March 16, 2026, Chinese tech forums erupted with reports that Qihoo 360 (奇虎360) — China's largest cybersecurity company with 461 million active users and a ~$10.5 billion market cap — had bundled the SSL/TLS private key for its wildcard certificate *.myclaw.360.cn inside the installer package for "360 Security Claw" (360安全龙虾), their one-click deployment wrapper for the open-source OpenClaw AI agent framework [1]. The private key was discovered inside the openclaw.7z archive at the path namiclaw/components/Openclaw/openclaw.7z/credentials, accessible to anyone who downloaded the installer [2].​‌‌‌​​​‌‍​‌‌​‌​​‌‍​‌‌​‌​​​‍​‌‌​‌‌‌‌‍​‌‌​‌‌‌‌‍​​‌​‌‌​‌‍​​‌‌​​‌‌‍​

​‌‌​‌‌​‍​​‌‌​​​​‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌‌​​‍​‌‌​​​​‌‍​‌‌‌​‌‌‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌‌​​‌‌‍​‌‌​‌‌​​‍​​‌​‌‌​‌‍​‌‌‌​​​​‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌‌​‍​‌‌​​​​‌‍​‌‌‌​‌​​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌​‌​‌‌‍​‌‌​​‌​‌‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌​‌‌​​‍​‌‌​​‌​‌‍​‌‌​​​​‌‍​‌‌​‌​‌‌

The certificate, issued by WoTrus CA Limited on March 12, 2026, is valid for one year (until April 12, 2027) and covers all subdomains under myclaw.360.cn [5]. X (formerly Twitter) users posted the full PEM-encoded certificate and private key publicly, with one post garnering over 22,800 views within hours [6]. Grok, X's AI assistant, analyzed the leak and concluded: "After the private key is leaked, anyone can forge TLS connections for this domain, security is completely compromised. 360 needs to immediately revoke and replace" [2].

Why Does an SSL Private Key Leak Matter?

SSL/TLS certificates use public-key cryptography to establish encrypted connections between browsers and servers. The certificate (public key) is meant to be public — it's what browsers use to verify they're talking to the legitimate server. The private key must remain secret; it's what the server uses to prove its identity and decrypt traffic [7].​‌‌‌​​​‌‍​‌‌​‌​​‌‍​‌‌​‌​​​‍​‌‌​‌‌‌‌‍​‌‌​‌‌‌‌‍​​‌​‌‌​‌‍​​‌‌​​‌‌‍​​‌‌​‌‌​‍​​‌‌​​​​‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌‌​​‍​‌‌​​​​‌‍​‌‌‌​‌‌‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌‌​​‌‌‍​‌‌​‌‌​​‍​​‌​‌‌​‌‍​‌‌‌​​​​‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌‌​‍​‌‌​​​​‌‍​‌‌‌​‌​​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌​‌​‌‌‍​‌‌​​‌​‌‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌​‌‌​​‍​‌‌​​‌​‌‍​‌‌​​​​‌‍​‌‌​‌​‌‌

When a wildcard private key like *.myclaw.360.cn leaks, an attacker can impersonate any subdomain on that platform. With Qihoo 360's leaked key, an attacker can:

  1. Conduct man-in-the-middle (MITM) attacks — intercept traffic between users and any myclaw.360.cn service, decrypt it in real-time, and steal API keys, credentials, or AI agent configurations [8]
  2. Create convincing phishing sites — host a fake login page at secure.myclaw.360.cn with a valid, browser-trusted HTTPS certificate showing the green padlock [9]
  3. Hijack AI agent sessions — if OpenClaw agents communicate with cloud services via myclaw.360.cn domains, attackers can intercept prompts, API calls, or training data [10]
  4. Maintain access until April 2027 — unless 360 revokes the certificate, the leaked key remains exploitable for over a year [5]

According to NIST SP 800-57, compromised private keys must be revoked immediately and replaced with newly generated key pairs [11]. Certificate revocation happens via Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP), but many clients don't check revocation status aggressively, leaving a window of vulnerability even after revocation [12].

The Irony: A Cybersecurity Giant's Self-Inflicted Wound

Qihoo 360 is not a startup — it's China's dominant cybersecurity player. Founded in 2005 by Zhou Hongyi (周鸿祎), the company's products include 360 Safeguard (antivirus), 360 Secure Browser, and 360 Mobile Safe, collectively protecting 461 million users [13]. The company is so significant that the U.S. Bureau of Industry and Security placed it on the Entity List in May 2020, accusing 360 of "enabling China's high-technology surveillance" in Xinjiang [14].

On March 10, 2026 — just six days before the leak was discovered — Zhou Hongyi announced 360 Security Claw with the promise of "one-click deployment, never leaks passwords, never deletes data" [3]. That same day, China's National Internet Emergency Response Center (CNCERT) issued a security advisory warning about OpenClaw risks including prompt injection, API key leakage, and malicious skill packages [15]. The next day, 360 published its own "OpenClaw Security Deployment Guide," with Zhou warning that "raising lobsters requires caution" (a play on OpenClaw's Chinese nickname "龙虾" or "lobster") [16].

Then, on March 12, 360 obtained the TLS certificate from WoTrus CA — and inexplicably bundled the private key into their publicly distributed installer [5]. The certificate was issued by WoTrus CA Limited, a Chinese certificate authority formerly known as WoSign. In 2016, Mozilla, Apple, and Google announced they would distrust WoSign certificates due to backdating, SHA-1 issuance after deprecation, and failure to disclose ownership changes [4]. WoTrus rebranded from WoSign in 2016 but remains controversial in the web PKI community [17].

Zhou Hongyi had compared AI agents to "interns" that need "strict rules" to prevent mistakes [16]. The meta-irony: 360 shipped a mission-critical private key in a compressed archive on day one.

What This Means for Supply Chain Security

The 360 Security Claw leak is a textbook supply chain security failure. Supply chain attacks exploit trust relationships — users trust that a major cybersecurity vendor won't bundle private keys in their installer [18]. According to the 2025 Verizon Data Breach Investigations Report, software supply chain compromises have increased 300% since 2023, with pre-installed malware and misconfigurations in vendor-distributed packages accounting for 18% of breaches [19].

The NamiClaw component — 360's wrapper around the open-source OpenClaw project — included the openclaw.7z archive containing the credentials directory. This means every user who downloaded the installer to simplify their OpenClaw deployment inadvertently received the keys to 360's kingdom [2]. In supply chain security terms, this is known as "vendor-introduced risk" — the supplier (360) creates the vulnerability, and every downstream customer inherits it [20].

NIST's Secure Software Development Framework (SSDF) recommends that vendors "protect all forms of code from unauthorized access and tampering" and specifically calls out secrets management as a critical control [21]. The SSDF explicitly states: "Private keys and other secrets should never be embedded in software distributions" [22]. For an organization of Qihoo 360's size and reputation, this failure suggests either process breakdown (lack of pre-release security scanning) or cultural issues (security theater over substance).

Chinese Government Response: AI Agent Risk Awareness

The same week 360 Security Claw launched, Chinese government agencies issued multiple warnings about AI agent security risks. On March 10, CNCERT published an advisory listing prompt injection, API key leakage, and malicious skill packages as top risks when deploying OpenClaw and similar AI agent frameworks [15]. The Ministry of Industry and Information Technology (MIIT) echoed these warnings, and Xinhua News Agency published "Six Do's and Don'ts for OpenClaw Security" on March 12 [23].

The China Academy of Information and Communications Technology (CAICT) added that "upgrading to the latest versions doesn't eliminate all risks," emphasizing the need for manual security reviews even with vendor-provided installers [24]. This official guidance makes 360's private key leak even more damaging — the government was actively warning about AI security hygiene while 360 was violating the most basic PKI practices.

FAQ

A wildcard SSL certificate like *.myclaw.360.cn covers all subdomains under a domain (e.g., api.myclaw.360.cn, admin.myclaw.360.cn, secure.myclaw.360.cn). Leaking its private key means an attacker can impersonate any of these subdomains with a valid, browser-trusted HTTPS certificate, making phishing and man-in-the-middle attacks trivial [7].

Users on L站 (Linux.do), a Chinese tech forum, inspected the 360 Security Claw installer package and found the openclaw.7z archive containing a credentials directory with the full PEM-encoded certificate and private key [1]. The discovery spread to X (Twitter), where multiple users posted screenshots and analysis [6].

Yes, 360 should immediately revoke the certificate via WoTrus CA and issue a new one with a freshly generated private key. However, certificate revocation checking is inconsistent — many browsers and tools don't aggressively verify OCSP or CRL status, so attackers may still exploit the leaked key for weeks or months [12].

WoTrus CA (formerly WoSign) was removed from major browser trust stores in 2017 due to misissuance practices, including backdating certificates and issuing SHA-1 certificates after deprecation [4]. The CA was later re-included under the WoTrus brand, but the history raises questions about oversight and trustworthiness [17].

Users should assume any traffic to *.myclaw.360.cn domains could be intercepted. If you configured OpenClaw to use 360's cloud services, rotate all API keys and credentials immediately. Monitor for unexpected login attempts or data access. Consider switching to self-hosted OpenClaw deployments that don't rely on 360's infrastructure [10].

Lessons for Your Own Infrastructure

This incident isn't just a Qihoo 360 problem — it's a reminder that secrets management failures can happen to anyone, even industry leaders. Here's what to audit in your own environment:

  1. Never bundle private keys in application packages — use secret injection at runtime via environment variables, secret managers (AWS Secrets Manager, HashiCorp Vault), or hardware security modules (HSMs) [25]
  2. Scan releases before distribution — tools like trufflehog, gitleaks, and detect-secrets catch accidentally committed keys [26]
  3. Certificate lifecycle management — track all TLS certificates, set expiry alerts 30 days out, and have a revocation playbook ready [27]
  4. Supply chain verification — if you're distributing vendor wrappers or repackaged open-source tools, audit what's in the bundle [18]
  5. Principle of least privilege — wildcard certificates are convenient but dangerous; use single-domain or SAN certificates when possible to limit blast radius [28]

References

[1] "360安全龙虾SSL私钥泄露事件," channel.0w0.best (L站中继), Mar. 2026. [Online]. Available: https://channel.0w0.best

[2] @Grok, "Qihoo 360 Security Claw SSL Analysis," X (Twitter), Mar. 16, 2026. [Online]. Available: https://x.com/grok

[3] Zhou Hongyi, "360安全龙虾发布会," Sina Finance, Mar. 10, 2026. [Online]. Available: https://finance.sina.com.cn

[4] Mozilla Security Blog, "Distrusting WoSign and StartCom Certificates," Mozilla, Oct. 2016. [Online]. Available: https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/

[5] @Nyarime, "360 Security Claw Certificate Posted," X (Twitter), Mar. 16, 2026. [Online]. Available: https://x.com/Nyarime

[6] @realNyarime, "360安全龙虾私钥泄露," X (Twitter), Mar. 16, 2026. [Online]. Available: https://x.com/realNyarime

[7] NIST, "SP 800-52 Rev. 2: Guidelines for TLS Implementations," NIST, 2019. [Online]. Available: https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final

[8] M. Georgiev et al., "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software," ACM CCS, 2012, pp. 38-49.

[9] A. Oest et al., "PhishFarm: A Scalable Framework for Measuring the Effectiveness of Evasion Techniques against Browser Phishing Blacklists," IEEE S&P, 2019, pp. 1344-1361.

[10] "OpenClaw安全部署指南," BAAI/智源社区, Mar. 11, 2026. [Online]. Available: https://hub.baai.ac.cn

[11] NIST, "SP 800-57 Part 1 Rev. 5: Recommendation for Key Management," NIST, May 2020. [Online]. Available: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final

[12] Y. Liu et al., "An End-to-End Measurement of Certificate Revocation in the Web's PKI," ACM IMC, 2015, pp. 183-196.

[13] "奇虎360公司简介," Qihoo 360 Investor Relations, 2025. [Online]. Available: https://ir.360.cn

[14] U.S. Bureau of Industry and Security, "Addition of Entities to the Entity List," Federal Register, May 22, 2020. [Online]. Available: https://www.federalregister.gov/d/2020-11283

[15] CNCERT, "OpenClaw安全风险提示," National Internet Emergency Response Center, Mar. 10, 2026. [Online]. Available: https://www.cert.org.cn

[16] "周鸿祎：养龙虾需谨慎," Sina Tech, Mar. 11, 2026. [Online]. Available: https://tech.sina.com.cn

[17] R. Sleevi, "Sustaining Digital Certificate Security," Google Security Blog, Mar. 2017. [Online]. Available: https://security.googleblog.com/2017/03/sustaining-digital-certificate-security.html

[18] CISA, "Defending Against Software Supply Chain Attacks," CISA, Apr. 2021. [Online]. Available: https://www.cisa.gov/supply-chain

[19] Verizon, "2025 Data Breach Investigations Report," Verizon Enterprise, 2025. [Online]. Available: https://www.verizon.com/business/resources/reports/dbir/

[20] NIST, "SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices," NIST, May 2022. [Online]. Available: https://csrc.nist.gov/publications/detail/sp/800-161/rev-1/final

[21] NIST, "Secure Software Development Framework (SSDF) Version 1.1," NIST, Feb. 2022. [Online]. Available: https://csrc.nist.gov/publications/detail/sp/800-218/final

[22] NIST, "SSDF Practice PW.7: Protect All Forms of Code from Unauthorized Access," NIST SSDF Guidance, 2022.

[23] Xinhua News Agency, "OpenClaw安全六大注意事项," Xinhua, Mar. 12, 2026. [Online]. Available: http://www.xinhuanet.com

[24] CAICT, "AI Agent安全风险分析," China Academy of Information and Communications Technology, Mar. 2026. [Online]. Available: http://www.caict.ac.cn

[25] AWS, "AWS Secrets Manager User Guide," Amazon Web Services, 2025. [Online]. Available: https://docs.aws.amazon.com/secretsmanager/

[26] "truffleHog: Find secrets in your code," GitHub, 2026. [Online]. Available: https://github.com/trufflesecurity/trufflehog

[27] A. Kasten et al., "Experiences from Monitoring and Analyzing Certificate Ecosystem Health," ACM IMC, 2020, pp. 606-620.

[28] CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates," CA/B Forum, v2.0.3, 2024.

Your infrastructure deserves better than crossed fingers and hope. If you're managing certificates, secrets, or supply chain risk without clear visibility, you're one installer away from your own headline. Let's talk about building security that scales with your business — book a free consult.

TL;DR

  • China's biggest security company (Qihoo 360, 461 million users) accidentally gave everyone the digital key to their website when they released new software [1]
  • It's like a bank putting the vault combination inside every promotional brochure they hand out on the street [2]
  • Anyone with the key can pretend to be the real website and steal passwords, even though their browser says it's safe with the padlock icon [3]
  • The irony: the company's founder promised "we'll never leak your passwords" just days before accidentally leaking their own master key [4]

What's an SSL Key Anyway?

When you visit a website with https:// and see a little padlock icon in your browser, that means the website is using something called an SSL certificate. Think of it like a special ID card that proves "yes, this really is the Bank of America website, not a fake copy" [5].

The SSL certificate has two parts, kind of like a house lock:

  • The public key (the lock itself) — everyone can see it, and that's totally fine
  • The private key (the special key that opens the lock) — only the website owner should have this

When you send your password to a website, it gets scrambled using the public key. Only someone with the private key can unscramble it and read it [6]. That's what keeps your secrets safe when you're shopping online or logging into email.

What Did Qihoo 360 Do Wrong?

Qihoo 360 is like the biggest security guard company in China. They make antivirus software, safe web browsers, and tools that protect 461 million people's computers [7]. On March 10, 2026, they released new software called "360 Security Claw" that was supposed to help people set up AI robot assistants on their computers [1].

The boss, Zhou Hongyi, promised: "Our software will never leak your passwords and never delete your data" [4]. Sounds great, right?

But here's what actually happened: Inside the software download, buried in a compressed folder, Qihoo 360 included their private key — the master key that unlocks all the myclaw.360.cn websites [8]. Anyone who downloaded the software got the key. It's like McDonald's accidentally printing the safe combination on every Happy Meal box.

A few days later, people on Chinese tech forums noticed it and posted screenshots on the internet. One post got over 22,800 views [9]. The private key was just sitting there in a folder called credentials inside a file called openclaw.7z [2].

Why Is This So Bad?

Imagine you run a lemonade stand, and you have a special stamp that says "Official Monster's Lemonade — Safe to Drink!" You use that stamp on all your cups so people know it's really from you and not poisoned fake lemonade from the sketchy stand across the street.

Now imagine you accidentally gave everyone in town a copy of your stamp. The fake lemonade guy can now stamp his cups with "Official Monster's Lemonade" and people will trust it, even though it's not really from you [10].

That's what happened with Qihoo 360's SSL key. With that private key, a bad guy can:

  1. Make a fake website that looks 100% real — complete with the green padlock and https:// that your browser shows when a site is "secure" [11]
  2. Steal everyone's passwords — when you type your password thinking you're on the real site, you're actually sending it to the attacker [12]
  3. Read secret messages — if robot assistants (AI agents) are talking to 360's servers, attackers can listen in and see everything [13]

The certificate is valid until April 2027, so attackers have over a year to use it unless 360 cancels it [8]. Even if they do cancel it, many web browsers don't check if certificates are canceled, so people might still trust the fake websites for weeks or months [14].

The Irony: A Security Company Making the Biggest Security Mistake

Qihoo 360 isn't some small startup — they're the biggest security company in China. They've been protecting computers since 2005 [7]. The U.S. government even put them on a special list in 2020 because they're so important to China's technology [15].

So when the founder promises "we'll never leak passwords" and then immediately ships software with their own master password inside... that's like a firefighter showing up to put out your house fire while their own truck is on fire behind them.

What makes it even funnier (in a "this shouldn't be funny but it is" way):

  • March 10: Zhou promises the software is super safe [4]
  • March 10: China's internet safety center warns everyone about AI robot security risks [16]
  • March 11: 360 publishes a guide about "how to stay safe with AI robots" [17]
  • March 12: They get the SSL certificate from WoTrus (a company that got kicked out of web browsers in 2017 for being untrustworthy) [18]
  • March 15-16: People find the private key in the download and post it online [9]

Zhou Hongyi said AI robots are like "interns who need strict rules so they don't mess up" [17]. Turns out his own company needed strict rules about not putting secret keys in public downloads.

What Should You Learn From This?

Even the biggest, most famous security companies can make huge mistakes. Here's what this teaches us:

  1. Don't put secrets in files that everyone downloads — if you're making an app or a website, never include passwords, keys, or secret codes in the download. Load them separately after someone installs it [19]
  2. Check before you ship — there are special programs (like trufflehog and gitleaks) that scan your files and yell at you if they find passwords or keys [20]
  3. Wildcard certificates are risky — a wildcard certificate (one that works for *.myclaw.360.cn) means one leaked key breaks ALL the websites at once. It's like using the same key for your house, your car, your bike lock, and your school locker — if you lose it, everything is unlocked [21]
  4. Big companies aren't always safer — Qihoo 360 has 461 million users and still made this mistake. Don't assume "they're huge, they must know what they're doing" [7]

FAQ

A regular SSL certificate protects one website, like shop.example.com. A wildcard certificate uses a star (*) and protects ALL subdomains, like shop.example.com, admin.example.com, api.example.com, etc. [21]. It's convenient but dangerous — if the key leaks, all the sites are compromised at once.

Normally, when you visit secure.myclaw.360.cn, your browser asks the server "prove you're really the real server" by doing a secret handshake using the private key. If a bad guy has the private key, they can do the same handshake and your browser thinks they're legit [3]. They can set up a fake website at a slightly different address (maybe using a typo or a misleading link) and your browser shows the green padlock like everything is safe [11].

Yes, they can "cancel" the certificate (called revoking it) and make a new one with a new private key [14]. But many web browsers don't check if certificates are canceled, so attackers might still be able to use the leaked key for a while. The best fix is for 360 to cancel the old certificate AND tell everyone to stop using their software until they release a fixed version [22].

WoTrus CA is a Chinese company that gives out SSL certificates. They used to be called WoSign, but in 2017, Google, Mozilla, and Apple all stopped trusting them because they kept making mistakes with certificates [18]. They changed their name to WoTrus and got back into browsers, but a lot of security experts still don't trust them. It's weird that a major security company would use them instead of a more reliable certificate authority [23].

If you installed 360 Security Claw, assume anything you typed into *.myclaw.360.cn websites might have been stolen. Change your passwords, remove the software, and use the regular OpenClaw installer instead (the open-source version that 360 was wrapping) [13]. Check your accounts for weird login attempts.

What You Can Do

If you're building a website or an app, here are simple rules to avoid your own "oops, I leaked the keys" moment:

  1. Use a password manager or secrets tool — never put passwords in your code [19]
  2. Scan your code before releasing it — free tools can catch secrets you forgot about [20]
  3. Get your SSL certificates from a trusted authority — not from companies that got kicked out of browsers [18]
  4. Use different keys for different things — one key for your website, a different key for your API, etc. [21]
  5. Have a "what if we mess up?" plan — know how to cancel certificates fast and tell your users [22]

Security is hard. Even the experts mess it up. But if the biggest security company in China can ship a private key on launch day, imagine what could happen if you don't double-check your own stuff.

References

[1] "360安全龙虾SSL私钥泄露事件," channel.0w0.best (L站中继), Mar. 2026. [Online]. Available: https://channel.0w0.best

[2] @realNyarime, "360安全龙虾私钥泄露," X (Twitter), Mar. 16, 2026. [Online]. Available: https://x.com/realNyarime

[3] E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3," IETF RFC 8446, Aug. 2018. [Online]. Available: https://www.rfc-editor.org/rfc/rfc8446

[4] Zhou Hongyi, "360安全龙虾发布会," Sina Finance, Mar. 10, 2026. [Online]. Available: https://finance.sina.com.cn

[5] S. Santesson et al., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile," IETF RFC 5280, May 2008. [Online]. Available: https://www.rfc-editor.org/rfc/rfc5280

[6] NIST, "SP 800-52 Rev. 2: Guidelines for TLS Implementations," NIST, 2019. [Online]. Available: https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final

[7] "奇虎360公司简介," Qihoo 360 Investor Relations, 2025. [Online]. Available: https://ir.360.cn

[8] @Nyarime, "360 Security Claw Certificate Posted," X (Twitter), Mar. 16, 2026. [Online]. Available: https://x.com/Nyarime

[9] @ZaihuaNews, "360安全龙虾事件传播," X (Twitter), Mar. 16, 2026. [Online]. Available: https://x.com/ZaihuaNews

[10] M. Georgiev et al., "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software," ACM CCS, 2012, pp. 38-49.

[11] A. Oest et al., "PhishFarm: A Scalable Framework for Measuring the Effectiveness of Evasion Techniques," IEEE S&P, 2019, pp. 1344-1361.

[12] D. Akhawe et al., "Here's My Cert, So Trust Me, Maybe? Understanding TLS Errors on the Web," WWW, 2013, pp. 59-70.

[13] "OpenClaw安全部署指南," BAAI/智源社区, Mar. 11, 2026. [Online]. Available: https://hub.baai.ac.cn

[14] Y. Liu et al., "An End-to-End Measurement of Certificate Revocation in the Web's PKI," ACM IMC, 2015, pp. 183-196.

[15] U.S. Bureau of Industry and Security, "Addition of Entities to the Entity List," Federal Register, May 22, 2020. [Online]. Available: https://www.federalregister.gov/d/2020-11283

[16] CNCERT, "OpenClaw安全风险提示," National Internet Emergency Response Center, Mar. 10, 2026. [Online]. Available: https://www.cert.org.cn

[17] "周鸿祎：养龙虾需谨慎," Sina Tech, Mar. 11, 2026. [Online]. Available: https://tech.sina.com.cn

[18] Mozilla Security Blog, "Distrusting WoSign and StartCom Certificates," Mozilla, Oct. 2016. [Online]. Available: https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/

[19] OWASP, "Secrets Management Cheat Sheet," OWASP, 2025. [Online]. Available: https://cheatsheats.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

[20] "truffleHog: Find secrets in your code," GitHub, 2026. [Online]. Available: https://github.com/trufflesecurity/trufflehog

[21] CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates," CA/B Forum, v2.0.3, 2024.

[22] NIST, "SP 800-57 Part 1 Rev. 5: Recommendation for Key Management," NIST, May 2020. [Online]. Available: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final

[23] R. Sleevi, "Sustaining Digital Certificate Security," Google Security Blog, Mar. 2017. [Online]. Available: https://security.googleblog.com/2017/03/sustaining-digital-certificate-security.html

Building something? Let's make sure it doesn't end up as a cautionary tale. We help small businesses get security right from day one — no jargon, no fear tactics, just practical protection that fits your budget. Start with a free chat.

Ready to strengthen your security?

Talk to lilMONSTER. We assess your risks, build the tools, and stay with you after the engagement ends. No clipboard-and-leave consulting.

Get a Free Consultation