Important Notice: Deprecation of OCSP for HARICA Publicly-Trusted TLS Certificates

Dear HARICA Subscribers,

Effective March 2, 2026, HARICA will officially deprecate the use of the Online Certificate Status Protocol (OCSP) for all newly issued publicly-trusted server TLS certificates, with exceptions made only for specific use cases where required.

In accordance with evolving industry standards and browser requirements, certificates issued after this date will no longer contain an OCSP responder URL in the Authority Information Access (AIA) extension, by default. Instead, certificate revocation status will be managed exclusively through Certificate Revocation Lists (CRLs) and modern browser-native mechanisms.

Why is this change happening?

The industry-wide move away from OCSP is driven by three primary factors:

1. User Privacy: Standard OCSP requests are unencrypted. When a browser checks a certificate’s status via OCSP, it informs the CA which IP address is visiting which website. Removing OCSP eliminates this privacy leak, ensuring that HARICA cannot track user browsing patterns.

2. Reliability and Performance: OCSP lookups often add significant latency to the TLS handshake (the “OCSP stapling” solution, while helpful, has seen inconsistent adoption). Furthermore, if an OCSP responder is slow or unreachable, it can cause “soft-fail” delays or “hard-fail” connection errors, impacting site availability.

3. Modern Revocation Standards: Browsers such as Apple Safari, Google Chrome and Mozilla Firefox have shifted toward more efficient, privacy-preserving methods for checking revocation at scale, such as CRLSets and CRLite. These methods rely on the CA publishing compressed CRLs rather than answering individual OCSP queries.

Timeline of Changes

• Today – March 1, 2026: No immediate action is required. HARICA will continue to support OCSP for all active certificates.
• March 2, 2026: All new TLS certificates issued by HARICA will omit the OCSP AIA extension by default. Certain exceptions will be allowed on a case-by-case basis.
• Post-March 2, 2026: Existing certificates issued prior to this date will continue to have functional OCSP support until their natural expiration. By May 4, 2027, we expect our public OCSP infrastructure to be fully decommissioned for TLS.

Impact on Subscribers

For the vast majority of subscribers, no action is required. Modern web browsers (Chrome, Safari, Firefox, and Edge) have already prepared for this transition.

However, a small number of “legacy” or “non-browser” applications that rely strictly on the presence of an OCSP URL in the certificate for hard-fail revocation checking may experience issues. We recommend the following:

• Review Legacy Systems: If you use specialized hardware or older software that requires OCSP for mutual TLS (mTLS) or specific compliance checks, ensure they support CRL-based revocation. If you operate legacy systems that rely exclusively on OCSP and cannot process CRLs, please contact our technical support team to discuss available options.
• OCSP Stapling: If you currently use OCSP Stapling on your web servers, the server will simply stop stapling a response once the new certificate (without an OCSP URL) is installed. This will not break the connection in modern browsers.

Our Commitment to Security

This change marks a meaningful step toward a faster, more private, and more resilient internet. We appreciate your continued trust in HARICA and remain committed to supporting you throughout this transition.

Upcoming changes regarding TLS Client Authentication in TLS Server Authentication Certificates

Dear HARICA Subscribers,

We are announcing an upcoming update to our Publicly-Trusted SSL/TLS Web Server Certificates.

Effective March 2, 2026, HARICA will no longer include the TLS Client Authentication (Client Auth) Extended Key Usage (EKU) value by default in newly issued TLS Server certificates that chain to the Chrome Root Store.

Why are we making this change?

This update is required by the Google Chrome Root Program Policy. It strengthens security by ensuring that server authentication certificates are restricted strictly to server authentication.

How does this affect you?

For Standard Web Servers (HTTPS): There is no impact. Certificates used solely to secure a website and issued prior to the effective date will remain valid and functional until their expiration date.

For Mutual TLS (mTLS) Configurations: If you currently use the same certificate to identify your server to clients and to authenticate your server as a client to other back-end systems, you must take action.

Action Required: If your system requires Client Authentication:

• You must issue a dedicated Client Certificate (S/MIME or dedicated Client Auth) for that specific purpose. HARICA offers such certificates.
• If your solution does not support two distinct client and server authentication certificates, you need to document your use case in detail and explain why the two-certificate approach is not feasible. HARICA may grant an extension to this effective date on a case-by-case basis allowing more time for you to implement the necessary changes using two certificates. This extension cannot exceed May 15, 2026.
• Based on industry best practices, use cases relying on mTLS should use a Private PKI instead of Publicly-Trusted Certificates. You may contact sales@harica.gr for more information about these solutions.

Do you have any additional questions or concerns?

If you have questions or need more information, please contact the HARICA support at support@harica.gr.

Implementation of Multi-Perspective Issuance Corroboration (MPIC) and Mandatory CAA Checks for Mailbox Addresses

Multi-Perspective Issuance Corroboration (MPIC)

Starting on March 15, 2025, HARICA will implement Multi-Perspective Issuance Corroboration (MPIC) for Domain Authorization, Control, and Certification Authority Authorization (CAA) Record checks before issuing any TLS Server Authentication Certificates, in accordance with CA/B Forum Baseline Requirements for TLS Server Certificates.

With MPIC, DNS queries for Domain Validation and CAA checks must be verified from multiple, randomly distributed and distant locations across the Internet. If the information corroboration fails (up to a certain level), the certificate issuance will be blocked. Domain Owners must ensure that their Authoritative DNS servers are accessible from the global Internet, allowing the corroboration to be completed without failures that would prevent certificate issuance.

We remind our Subscribers that Publicly-Trusted TLS Server Authentication Certificates are “intended to be used for authenticating servers accessible through the Internet”, as described in the CA/Browser Forum TLS Baseline Requirements.

Mandatory CAA Checks for Mailbox Addresses

Effective March 15, 2025, HARICA will also be required to perform CAA checks for Mailbox Addresses, as mandated by the CA/Browser Forum S/MIME Baseline Requirements.

What You Need to Know:

• Before issuing an S/MIME certificate that includes a Mailbox Address, HARICA will retrieve and process CAA records, similar to the process used for TLS Certificates.
• If your DNS CAA record contains the issuemail tag, it must explicitly include the value “harica.gr”, authorizing HARICA for S/MIME certificate issuance.
• If no issuemail tag is present, no action is required.

HARICA introduces new 2021 hierarchy for SSL/TLS Certificates

We are pleased to announce that on the 1st of June 2022, HARICA will switch the issuance of SSL/TLS certificates to its 2021 Root TLS Certification Authorities.

Both HARICA TLS RSA Root CA 2021 and HARICA TLS ECC Root CA 2021 are already pre-installed on Windows operating systems as well on macOS 12 providing the necessary trust anchor for Google Chrome, Microsoft Edge and other popular Internet Browsers. In addition, Mozilla Firefox has updated its Certificate Store with HARICA’s new RootsCAs.

For older operating systems and browsers, HARICA issued two additional cross-certificates to chain the 2021 hierarchy with the older 2015 one for increased ubiquity.

Both HARICA TLS Root 2021 ECC and RSA cross-certificates can be used by our subscribers in their certificate chain files to cover the majority of browsers regardless of their version.

DV certificates for Onion websites

UPDATE

Following the high demand for onion certificates, HARICA decided to extend the discount period till the end of August 2021.

Great news for Onion fans!

We are excited to announce that HARICA has started issuing Domain Validated (DV) certificates for v3 Onion websites.

HARICA is a Publicly Trusted Certification Authority (CA) that participates in all major Global “ROOT CA” Trust Programs (360, Adobe, Apple, Microsoft, Mozilla, Oracle), and operates as a “Trust Anchor” in widely used Application Software and Operating Systems (Adobe, Apple, Google, Microsoft, Mozilla, Linux).

Following this announcement, we offer a discount to all HARICA’s DV Certificates, which includes “onion”, “wildcard onion”, and other types of publicly trusted DV TLS Certificates, starting at 4.5€ per year till the end of June 2021 [EXTENDED to August 2021].

Get yours now at HARICA’s CertManager!

How to purchase your own DV certificate?

• Create a HARICA account at HARICA’s CertManager.
• Under the Certificates section on the left, choose Server Certificates and make a new request for your domain.
• You have the Option to auto-generate your TLS CSR locally or manually submit one you have already prepared. Both RSA and ECDSA keys are supported.
• To validate your Domain Name you have three (3) “general purpose” validation options:
  1. Select a pre-defined email address of your domain to receive a confirmation email.
  2. Upload a text file, provided by HARICA, to a specific location on your web server.
     • For v3 Onion domains only this “general purpose” validation option is allowed. There is also a special option available which uses the Tor hidden service ed25519 key to generate a special “Onion CSR” to prove you control the v3 Onion domain namespace, which allows you to obtain a wildcard Onion certificate *.<hidden service>.onion. This is currently the only secure option allowed to obtain a wildcard Onion certificate and HARICA has built and publicly disclosed the necessary code to support this method!
  3. Add a DNS TXT record, provided by HARICA, to the selected authorization domain.
• After the successful payment of your order, you can retrieve your certificate.

What is an “Onion Service”?

Onion services are anonymous network services that are accessed via the Tor Browser and the underlying Tor (a.k.a. “Onion”) network. Clients use Onion services via Onion domains that are only resolvable inside the Tor network. In contrast to conventional Internet services, Onion services are private and end-to-end encrypted, generally not indexed by search engines, and use self-certifying domain names that are long and difficult for humans to read. That is, you can offer a web server, SSH server, etc., without revealing the real IP address to its users.

Why would an Onion website need a TLS certificate?

There is a list of reasons as to why an Onion website would need a TLS certificate:

• Mixing HTTP and HTTPS creates complex setups for websites.
• To help the user verify that the Onion domain is indeed the site you are hosting (manual check at the certificate registration information).
• Some services work with protocols, frameworks, and other infrastructure that have HTTPS connection as a requirement.
• In case your web server and your Tor process are in different machines.