HARICA Cert Manager is available at: https://cm.harica.gr. HARICA services can also be accessed via the API - API documentation can be found here: https://developer.harica.gr/ and https://guides.harica.gr/docs/Guides/Developer/1.-Register-and-log-in/.
https://cm-stg.harica.gr/ can be used to test and get to know the service.
Please use the following support address: support-tcs@harica.gr.
Please see: TCS Certificate Types 2025
The process is shown in the image below:
There are detailed support guides available at: https://guides.harica.gr/.
The following guides have also been created to explain the "Enterprise" workflow used for TCS:
TCS members that are also Identity Providers in eduGAIN must release the following attributes:
and may also release:
to the following HARICA EntityIDs:
Known issues:
EV certificates are NOT included in the HARICA TCS offer as we no longer see any value in supporting this certificate type as a default option. It is possible to purchase these (EV TLS) and other types of certificates (Code Signing, Qualified Electronic Signatures/Seals, QWACs) and remote signing services on an individual basis from HARICA if required for specific use cases.
This is available at: https://repo.harica.gr/rep_dyn.
Domain Validation (DV), Organisation Validation (OV) and Extended Validation (EV) certificates were designed to give a different level of confidence in the certificate types because the Certificate Authority carries out more stringent checks on the organisation requesting the certificate at each level. Browsers used to signal this in the address bar, and the idea was the user could make different decisions based on this security level. Placing this level of technical knowledge on the user has now been broadly debunked and this information is no longer prominently signalled.
For the same key size and encryption algorithm DV/OV/EV certs are indistinguishable in terms of encryption security. In most popular browsers, there is now no easily visible difference between these certificate types unless the user looks deep into the certificate settings. The increased levels of validation requirements also make automation harder, and with changes to certificate validity periods once more being discussed by the CA/B Forum, automation should now be considered essential by all organisations.
For the majority of use cases, DV certificates should serve your purposes well. You may find certain implementations or use cases still insist on OV or EV certificates and these can still be obtained via TCS (at an extra cost for EV), but we recommend using DV for most circumstances.
Let's Encrypt is a great free service and works well for many use cases, but has some limitations that a managed service like TCS can help with. This includes:
If you are seeing an issue where a HARICA certificate shows as not trusted or not valid, this typically means that the system using the certificate does not have access to the root or intermediary certificate. There's normally a way for these to be added - we suggest you contact the service owner or helpdesk for the service. All roots and intermediaries can be found at: https://repo.harica.gr/rep_dyn.
Some of examples of where we have found solutions to these problems:
Wildcard certificates can be requested using the normal processes. If you request a wildcard (e.g. *.geant.org) there's no need to also include geant.org in the request.
Firstly, the organisation must be configured to enable IGTF certificates. A “Tags” button has been added to the Enterprise Information page (upper right corner). This can be used to toggle IGTF certificate issuance on.
Organisations can then request an IGTF server certificate as part of the normal server workflow by ticking the appropriate box.
For single requests the users receive an expiration notification 30, 15, 5 and 1 day prior from the CertManager portal, to their email address which is in the certificate.
For bulk requests the users receive an expiration notification only 30 days prior, from the CA, to their email address which is in the certificate. The email is like the following message.
The certificate with serial number xxxxxxxxxxxx, for the entity with Distinguished Name E=xxxxx@auth.gr, CN=Aristotle University of Thessaloniki, O=Aristotle University of Thessaloniki,L=Thessaloniki,C=GR, which has been issued by CN=HARICA S/MIME RSA SubCA R3, O=Hellenic Academic and Research Institutions Cert. Authority,L=Athens,C=GR, expires on 2025-05-14 10:14:45+03:00.
When the s/mime certificates from bulk requests will be registered to s/mime certificates tab also, then the users will receive an expiration notification 30, 15, 5 and 1 day prior from CertManager portal, to their email address which is in the certificate.
For users logging into CertManager via SSO, whose identity provider supplies both the eduPersonPrincipalName (ePPN) and the entitlement urn:mace:terena.org:tcs:personal-user, the following options will be
available:
• GÉANT Personal Authentication
• GÉANT Personal Automated Authentication
Additionally, if the Enterprise admin has enabled the IGTF-Organization tag, the GÉANT Organization Automated Authentication option will also be available.
As discussed, the SubjectDN will be automatically ASCII-fied. However, if a custom ASCII-fied name is required, an Enterprise admin may submit a request directly to HARICA support at support-tcs@harica.gr.
We will then update the custom value in the Name ASCII-fied field under their Enterprise, which will override the automated ASCII-fication.
Finally, Enterprise Admins can assign the Client Authentication Approver role to members. While no approvals are required for IGTF client authentication certificates, since they are issued automatically, these approvers will still have visibility into all certificate requests submitted within their Enterprise.
There are two options for using ACME with HARICA
| Enterprise Admin | Available in all accounts | TLS OV | instead of ACME challenges, the validations in CertManager (in the list of domains) are used | (sub)domains both with include and exclude configurable in CertManager |
| Enterprise User (End Users) | Can be switched on manually (see below) | TLS DV | user must always do an ACME challenge (http or dns) for domain validation | all domains within the Enterprise |
A domain MUST have been added to the Enterprise before ACME can be used for that domain.
Enterprise Admins can create EAB (External Account Binding) credentials that can be used for specific domains. It is then possible to skip domain validation in your ACME client.
This is an additional implementation of ACME, which has functionally similar to Let's Encrypt: end users are given access (with a personal HMAC key) to an ACME server on which they can request certificates, as long as they can perform DCV during the ACME transaction.
This will make a new ACME button available to all users in the left menu to manage ACME accounts. When using Personal ACME, a DNS-01 or HTTP-01 challenge must be performed for each certificate and the HMAC key must be specified.
This can be avoided by agreeing to "Automated S/MIME Certificate Issuance via SAML Entitlement" permissions under the Enterprise information page. This will only be possible for SAML-enabled accounts as the SAML information is taken as equivalent to the identity vetting done by the CA.
