We propose an anomaly detection technique for X.509 certificates utilizing Isolation Forest. This method can be beneficial when compliance testing with X.509 linters proves unsatisfactory, and we seek to identify anomalies beyond standards compliance. The technique is validated on a sample of 120,000 certificates from one of the largest public Certificate Transparency (CT) tificates and detect misissued certificates. The details anyone, such as domain owners, to monitor issued cer- naissance regularly employs searches through CT logs to of CT operation, including participants, data structures, ample tools that use this technique, among other methDigital certificates, or public key certificates, issued by trusted certification authorities play an essential role in facilitating trust in security protocols. They bind the identity of a subject to a specific public key. Certificates that are issued mistakenly or with malicious intent pose a significant security threat, with impacts related to identity spoofing.
the CT log.
The most prominent public CT logs are operated by
Google, Cloudflare, and certification authorities
themall relevant certification authorities support CT, as of May
2024, over 460,000 certificates are published in CT logs
every hour [
The HTTP-based API that allows direct access to a
CT log is specified in RFC 9162 [
CEUR
ceur-ws.org
ITAT’24: Workshop on Applied Security, September 20–24, 2024, tics. Moreover, the model can be trained on certificates CEUR htp:/ceur-ws.org ISN1613-073
CEUR
Workshop Proceedings (CEUR-WS.org)
issued for specific domains, and anomalies detected in newly issued certificates can indicate an internal problem that needs to be addressed.
In our paper, we use the term “anomaly” to refer to certificates that are significantly diferent from those usually observed. We do not test certificates for compliance with X.509 standards like linters do6. However, in future work, it might be interesting to include linter results as additional attributes for anomaly detection, providing a more comprehensive analysis of certificate structures and content.
Our contribution. We evaluate selected statistical
information about certificates in CT logs, focusing on
attributes defined by domain owners, such as Subject
Alternative Name (SAN) in Section 2. We propose a method
for anomaly detection in certificates using Isolation
Forest [
We created a random sample of 120,000 records from one of the largest public Certificate Transparency (CT) CN=multimedia-academy.tudelft.nl, logs, Xenon 2024, which is operated by Google. In CT O=Technische Universiteit Delft, logs, there are two types of records: precertificates and ST=Zuid-Holland, certificates. Since all the features we want to extract are C=NL already available in precertificates, we do not discriminate between these types in our analysis. The presence and number of attributes in a DN can
According to the statistics presented by Cloudflare on vary. For instance, we found that approximately 2.28% of
their Merkle Town webpage [
Let us discuss what attributes we considered and selected for feature extraction. We group them in several categories – subject, subject’s public key, issuer, signature, validity, and X.509 extensions.
Subject. A distinguished name (DN) consists of a set of attributes that identify a subject. In the case of domain validated certificates, it usually contains just the common name (CN). For organization validated certificates, however, it may contain a set of attributes such as: 6It is important to note that X.509 linters check certificates against a specific set of rules, ensuring they conform to established standards.
Some well-known tools are ZLint and pkilint. • The length of a DN – this refers to the number of characters in the DN string representing a subject.
In our sample, DN lengths range from 0 to 278
characters with an average length of 33.0.
• The number of attributes in a DN – this represents
the inner structure of the DN and indicates how
many relative Distinguished Names (RDNs) are
present. The maximum value in our sample is 12
attributes, while the mean is 1.4 attributes, and
only 14.0% of records have an attribute count that
is not equal to 1.
• The length of a CN – this attribute focuses on
the most important and most frequently present
part of a DN. The maximal allowed length of 64
characters [
RSA ECDSA 24.4% * exactly one 8192-bit RSA key in the sample • CA rarity: A float number computed as a fraction of certificates in the sample with the same issuer (DN).
It is assumed that more common certification authorities have better practices and stricter certification policies in place, so their certificates are less likely to be anomalous. Therefore, we will not analyze other aspects of the issuer further.
Certainly, there might exist qualitative anomalies in certificates based on small diferences or variances that are not captured by quantitative characteristics alone. For example, some uncommon semantics may be used for DN attributes. These anomalies will not be detected with methods trained only on quantitative features. However, we do not attempt to analyze these anomalies in this paper as it would require interpreting diferent parts and attributes of the certificate beyond the scope of our experiment. This approach, focusing on quantitative characteristics, is also used for feature extraction in the rest of this section.
• Number of subdomains in a CN – this represents Signature. We do not extract any features from a
sigthe inner structure of CN. In our sample, the num- nature algorithm used by certification authorities to sign
ber of subdomains ranges from 0 to 15. (pre)certificates. This is entirely at their discretion, and
• Wildcard CN – a boolean value indicating we assume that CA rarity, see above, covers unusual
whether the CN contains a ‘*’ character. Wild- certification authorities suficiently in our experiment.
card CNs are observed in 12.0% of records. However, if someone wants to consider signatures in
anomaly detection, both types (algorithms) as well as
key lengths should be considered. Nice online statistics
covering signature algorithms are presented in [
Another set of attributes that might be considered in the future are embedded SCT (Signed Certificate Timestamps) in certificates. A certification authority can decide in which CT logs it wants to include a certificate. This decision is usually uniform across diferent certificates, taking into account their expiry date. An unusual combination or SCT count can indicate an anomaly.
Subject’s public key. A public key is another attribute that is fully controlled by the subject. The certificate authority can restrict the types and supported lengths of public keys for issued certificates, but the value is ultimately generated by the subject. We extract two features from the public key: its type and length.
• Public Key Type: There are only two types of subject public keys – RSA and Elliptic Curve Digital Signature Algorithm (ECDSA). Our sample shows a dominant position of RSA keys (73.5%).
We do not extract the type of elliptic curve used in ECDSA keys. A numeric encoding of public key type is performed as follows: ECDSA ↦ 0,
RSA ↦ 1. • Public Key Length: Bit length of the public key, depending on the modulus length for RSA or chosen curve for ECDSA. The observed variability of this attribute is presented in Table 1.
Issuer. Let’s Encrypt is the most prevalent certification authority, accounting for over 52% of certificates in our sample. The total number of distinct certification authorities, identified by unique DN, is 176. For anomaly detection, we will use the rarity of CA as a feature: Validity. Despite the validity period depends on the CA’s certification policy, our sample demonstrates significant variability within this attribute, ranging from one day to approximately 50 months. This feature is extracted for use in anomaly detection.
• Validity period: the number of days a certificate is valid, calculated as the diference between “not before” and “not after” dates. Approximately 70% of certificates in our sample are issued for a validity period of three months, predominantly due to Let’s Encrypt’s certification policy. Nearly 19.3% of the certificates have a validity period of approximately one year.
X.509 extensions. There are various extensions that
can be part of a certificate. Our experiment with anomaly
detection is focused mostly on attributes chosen by the
subject. Therefore, special attention is given to the
features of Subject Alternative Name (SAN) extension.
According to RFC 5280 [
In our sample, we found that 88.3% of certificates were DV, and 11.7% were OV, while other types occurred negligibly.
We decided not to analyze other extensions separately despite their potential interest, such as Key Usage, CRL, OCSP, and various constraints. Although problems or anomalies can be hidden in any of them, we selected a subset of attributes more related to the subject, because these attributes can help detect incorrect configurations when requesting certificates or possible covert communication. For other anomaly detection applications, it might be important to include specific X.509 extensions in the set of selected features. Our experiment focuses on the following summary characteristics: • Extensions count: The number of X.509 extensions in a certificate. The dataset shows this parameter ranging from 5 to 13 with 97.3% of records having 9 or 10 extensions. • Extensions size: The length of X.509 extensions in a certificate excluding SAN, since the related SAN characteristics – number and average length – are represented separately. The average size in our sample is 2306 bytes, while minimum and maximum sizes are 815 and 3506 bytes, respectively.
Isolation Forest is an unsupervised anomaly detection
technique proposed by Liu, Ting, and Zhou [
The Isolation Forest algorithm was selected for our experiment due to its ability to detect anomalies without relying on complex distance metrics or density estimation. Furthermore, Isolation Forest performs well in high-dimensional problems containing a large number of irrelevant attributes. Additionally, it can efectively train the model even when the anomalies are not present in the training sample. The technique also has low time and memory complexity.
We utilize an implementation of the Isolation Forest
provided in PyOD library [
The contamination of the data, i.e. the proportion of anomalies in the dataset, is irrelevant for the discussion in Section 4. The reason being that the contamination is only used to set an anomalous score threshold. Instead, we examine which data, specifically precertificates and certificates, have the highest anomalous scores. From these observations, conclusions can be drawn without requiring knowledge of the exact contamination value for our dataset.
We document the types of precertificates and certificates that are detected as the most anomalous in our exploratory experiment. A general observation is that some cloud services and their internal components are the most frequent outliers in our dataset.
Azure infrastructure. The most anomalous certificates in our experiment are those issued by Microsoft for the components of Azure infrastructure. The issuing CAs are: • Microsoft Azure TLS Issuing CA XX – several authorities, where XX denotes number 01, 02, etc.; • Microsoft Azure RSA TLS Issuing CA XX – again
several authorities issuing certificates; • Microsoft RSA TLS CA XX – significantly smaller number of certificates in comparison to the above two sets of authorities.
Table 2 summarizes basic characteristics for each CA. It shows above-average values, particularly for the first two CAs. Besides higher than usual number of SAN domain names, longer domain names and extensions, the other factors contribute to anomaly of detected certificates as well. Top anomalous certificates show various deviations, such as slightly odd validity period, the number of wildcard domain names, and other attributes, combined with relative rarity of issuing CA. In this regard, the anomaly detection works as intended. For example, the most anomalous certificate in the dataset according our trained model shows the following characteristics: • Common Name:
CN=*.table.preprod.core.windows.net • Issuer: Microsoft Azure TLS Issuing CA 06 • Validity period: 282 • SAN count: 52, the number of wildcard domain
names: 52 • The average number of subdomains: 7 • The number of extensions: 12, overall extension
size: 3206 Microsoft Azure TLS Issuing CA Microsoft Azure RSA TLS Issuing CA Microsoft RSA TLS CA
CN SAN length count/length Other CAs and ZeroSSL. After filtering out certificates issued by the CAs metioned above, we examined the top 100 anomalous items in greater detail. Among these, we observed: the fraction with an empty subject is rather large: 41.3%. Table 3 summarizes some characteristics of records issued by this CA. It’s an interesting observation that free certificates issued by Let’s Encrypt CA do not exhibit such anomalies7. • Two certificates issued by DigiCert: one for a
Chinese cloud service provider and one for a le- The problem with unusual length of the CN attribute is gitimate IT company. not unique to ZeroSSL CA. Similar certificates are issued • Two certificates issued by Amazon for its AWS by Let’s Encrypt. Again, possible explanation might be components. an error in certificate management automation. Domain • All remaining 96 certificates were issued by Ze- owners are probably not aware or simply do not care, roSSL CA, specifically by ZeroSSL ECC Domain since both CA ofers free certificates. An examples of Secure Site CA. These have an unusual structure: such CN (certificate issued by Let’s Encrypt) is empty subject (DN), and questionable SAN attributes containing a large number of repetitive gitlab.gitlab.gitlab.gitlab.gitlab.git. subdomains. Two examples are: testing.yikj.work – www.www.www.www.www.www.pay.
avito.sber.avito.avito.www.www. www.www.www.www.www.www.yandex. avito.yandex.pay.portalswebmail. blumebwww.od3.10cekub2b.k. webmail.ultagkhanub2b.k.webmemo. m.phpmyadmin.wokemtutankhanub2b.
k.webmail.ultagame.com – www.www.www.www.www.www.www.www.
www.www.www.www.www.www.www.www. www.www.www.www.www.www.www.www. www.www.www.www.www.www.www.www. www.www.www.www.www.www.www.www. www.www.www.www.www.www.www.www. www.www.calendario. panel-fiveheberg.fr
Other observations. Ignoring ZeroSSL-issued certificates and various additional infrastructure certificates by Apple, Cisco, Google, and other well-known companies, we have found several more entries that look interesting.
For example, a certificate issued by Let’s Encrypt CA
with the following set of SANs:
*.ajptzd.com, *.amklvv.com, *.aqcssg.com,
*.ccjytp.com, *.doeigp.com, *.egfnjv.com,
*.eydqoa.com, *.fvrnlf.com, *.guuzxk.com,
*.hgmwfy.com, *.iwhqyn.com, *.kldcuc.com,
*.lfmdnj.com, *.lloond.com, *.naktki.com,
*.nmklqi.com, *.npwpbz.com, *.nxezmi.com,
*.ojdger.com, *.psfqpu.com, *.ptgreh.com,
*.raclbc.com, *.rvaajo.com, *.spikfh.com,
*.swwoyd.com, *.tnuntp.com, *.xfcpkw.com,
*.xnrsre.com, *.xuvvdq.com, *.yyiosx.com
These might indicate an operational problem
with an automation script that issues and re- Most of these domains are unresolvable by public DNS
news certificates and adds www prefix to a domain (NXDOMAIN) as of May 2024. We did not investigate
name. Additionally, in case of the domain panel- this certificate further to determine whether it represents
fiveheberg.fr, combined with a wildcard DNS a legitimate use-case, misconfiguration, business
malrecord that positively responds to any DNS query. practice, or other malicious intent. However, based on
We checked both domains in VirusTotal, and no the experience documented in [
Not all precertificates and certificates issued by ZeroSSL ECC Domain Secure Site CA in our 7There are only 7 (pre)certificates with empty subject out of 62,424 dataset have the mentioned structure. However, issued by any Let’s Encrypt CA in our dataset. set all (pre)certificates empty subject indicating a likely malicious intent8. The other attributes of such certificates are rather normal, e.g., 90 days validity, 2048-bit RSA key or nine X.509 extensions, dictated mostly by the certification policy of Let’s Encrypt CA.
We proposed an anomaly detection technique for certificates using Isolation Forest. This approach can be beneficial when compliance testing with X.509 linters is unsatisfactory, and we seek anomalies beyond compliance. We demonstrated the feasibility of this method; however, further exploration is necessary. Some potential directions are: • Training the model on certificates for a specific domain or domains owned by a single entity, allowing anomalies to serve as early internal warnings of potential issues. • Identifying certificates from large cloud providers and excluding them from the model and evaluation. The CT logs contain a vast quantity of these precertificates and certificates, which can distort parameters of the model. • Analyzing the results of identified anomalies in greater detail, such as those described in the previous section, to find explanations for the anomalous certificates.
This publication is the result of support under the Operational Program Integrated Infrastructure for the project: Advancing University Capacity and Competence in Research, Development a Innovation (ACCORD, ITMS2014+:313021X329), co-financed by the European Regional Development Fund. 8A common tactic employed by large threat actors involves creating a script that randomly generates numerous domain names, purchasing them, and subsequently switching between domains as needed once one is blocked or otherwise compromised.