Updated Feb 17, 2026

Important Notice: We would like to inform you that, following the recent updates to the Chrome Root Program Policy and the extension of the deprecation timeline for the TLS Client Authentication EKU in TLS Server certificates, HARICA will postpone the previously announced actions by approximately nine (9) months.

The updated timeline will be communicated at a later date.

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.

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.

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.

• Allow minimal connections to computers with keys.
• Minimize the number of users who have key access.
• Use physical security controls to reduce access to keys.

• Cryptographic hardware does not allow export of the private key to software where it could be attacked.
• Use a FIPS 140 Level 2-certified product or a Common Criteria EAL 4+
• Use an EV code signing certificate which requires the private key to be generated and stored in hardware.
• Keep the token physically separate from the device that hosts the code signing function until a signing session is begun.
• If private keys will be transported, ensure that passwords are randomly generated with at least 16 characters containing uppercase letters, lowercase letters, numbers, and symbols.

• Time-stamping allows code to be verified after the certificate has expired or been revoked. Time-stamp certificates can be issued for a maximum of 135 months which can support the signed software to be validated for up to 11 years.

• Test-signing private keys and certificates requires less security access controls than production code signing private keys and certificates.
• Test-signing certificates can be self-signed or come from an internal test CA.
• Test certificates must chain to a completely different root certificate than the root certificate that is used to sign publicly released products; this precaution helps ensure that test certificates are trusted only within the intended test environment.
• Establish a separate test code signing infrastructure to test-sign pre-release builds of software.

• Any code that is submitted for signing should be strongly authenticated before it is signed and released.
• Implement a code signing submission and approval process to prevent the signing of unapproved or malicious code.
• Log all code signing activities for auditing and/or incident-response purposes.

• Code signing does not confirm the safety or quality of the code; it confirms the publisher and whether or not the code has been changed.
• Take care when incorporating code from other sources.
• Implement virus-scanning to help improve the quality of the released code.

• If code is found with a security flaw, then publishers may want to prompt a User Account Control dialogue box to appear when the code is installed in the future; this can be done by revoking the code signing certificate so a revoked prompt will occur.​
• If the code with the security flaw was issued before more good code was issued, then revoking the certificate will impact the good code as well.
• Changing keys and certificates often will help to avoid this conflict.

• Report key theft or signed malware to your issuing Certification Authority. Stolen keys or signed malicious code will require the code signing certificate to be revoked.
• If signed code is time-stamped, then the revocation date can be selected before the time of theft. This means that any code signed before the revocation date will remain valid.

Several years ago, an idea was born for an innovative (at the time) project based on the need for increased protection/security measures to encrypt communications over insecure networks, such as the Internet.

A team of Information and Communication Engineers from various Greek Universities and Research Centers collaborated and created a Public Key Infrastructure (PKI) that served and covered the security needs of the Academic and Research Institutions of Greece for SSL/TLS server and S/MIME certificates.

The project was successful and in the process our services were enriched, covering the growing needs of the Academic and Research Institutions. But we did not stop there. We wanted to offer our services outside the Academic/Research community.

Thus, we created the Certification Authority of the Hellenic Academic and Research Institutions (HARICA), which was initially supported by the National Research and Technology Network (GRnet) and then funded by the non-profit, civil company, Greek Universities Network (GUnet).

We started off by joining the Mozilla Root CA Program, which, even today, is the most strict and best supervised Global Certification Authority trust program, and gradually joined other major public trust programs.

After almost 15 years, HARICA is a Globally “Trusted Third Party” entity that simultaneously participates in all major Global “ROOT CA” Trust Programs (360, Adobe, Apple, Microsoft, Mozilla, Oracle) and operates as a “Trust Anchor” in International Software Companies and Operating Systems (Adobe, Apple, Google, Microsoft, Mozilla, Linux, Oracle Java).

Today HARICA’s services cover the full range of digital certificate needs and timestamps:

• from the basic security level on SSL / TLS servers for individuals, businesses, and organizations
• to the maximum level of security indication of large organizations (SSL EV, SSL QWAC, SSL QWAC-PSD2) fully meeting the requirements of Regulation (EU) 910/2014 (eIDAS) and Directive (EU) 2015/2366 on Payment Services (PSD2).

We provide products and services to individuals, companies and organizations:

• S/MIME, certificates for digital signing and encrypting emails,
• Code Signing, certificates used for digital software signing,
• E-Signature, “Qualified” Electronic Signatures which replace the handwritten signatures, as well as “Advanced” Electronic Signatures and
• E-Seal, electronic seals for Legal Entities, which, like its handwritten counterpart in the offline world, an electronic seal is a legal concept capturing the signatory’s intent to be bound by the terms of the signed document.

And we continue with the same enthusiasm, more structured and more experienced, improving and enriching our services offering the maximum security to our digital world.