Certipy: three names, six links, and four crypto stacks

Three names for one tool, and the package is the odd one out

The repository is Certipy, the command you type is certipy, and the project title on the page is an attack and enumeration toolkit for certificate services. The package on the index is called something else again: the manifest names it with an adjective suffix, and the badge at the top of the page links to that name rather than to the repository name. All four surfaces have to agree for a support question to make sense, and three of them are not the same string. It also means search results for the tool split across names, which is a small but real cost for anyone looking for prior art or existing scripts. Inside the manifest there is a single console entry point, so every subcommand hangs off one executable rather than a family of small commands, and the package structure mirrors that: a top level package, a commands package, a parsers package under it, and a library package.

The README is six sections and every one is a link

Count the sections on the page and there are six, separated by rules, and not one contains a command. The documentation section points at a wiki page described as a step by step usage guide covering installation, vulnerability explanations, examples and mitigations. Then installation points at its own wiki page. Then a quick start page. Then a supported vulnerabilities page. Then a resources page. Then the wiki again, this time described as carrying documentation, usage examples, vulnerability breakdowns and mitigation advice. So six sections, four destinations, one destination twice. What is genuinely useful in the page is the framing and the authorization warning, which asks you to use the tool only where you have explicit permission and notes that unauthorized use may be illegal. The wiki URLs carry percent-encoded punctuation and page numbers in the low single digits, so the wiki is a numbered book and this page is its index.

Every dependency is pinned to a major line, the crypto library included

The dependency list has eleven entries and every one uses the compatible release operator rather than a lower bound. In practice that means each package is pinned to a major version line with no upper bound stated: the cryptography library is held inside one major line, the ASN.1 library inside another, the LDAP library inside another. For most of these that is sensible restraint on a security tool. For the cryptography library it is worth a second look, because that is the package that receives the fixes when a certificate parsing flaw appears, and a compatible-release pin means your tool picks up patches within its major line and nothing outside it. The Python floor is modern, three point twelve or newer, and the formatter is configured to target that version, so the project is otherwise happy to be current about its interpreter while holding its libraries still.

Four cryptography and ASN.1 stacks in one list

Count the overlapping responsibilities in the dependency list and the number is higher than it first appears. There is a general purpose cryptography library. There is a separate asymmetric crypto library. There are two distinct ASN.1 implementations, one pure Python and one built on the cryptography library's own bindings. That is four libraries whose job overlaps, in a tool whose entire subject is X.509 certificates, PKCS structures and templates. The rest of the list is equally layered: two HTTP clients rather than one, an HTML parser for scraping the certificate authority's web enrolment pages, a directory access library, a DNS library, a completion library, and the toolkit this project is built on top of, which is itself an offensive Active Directory and SMB toolkit rather than a set of primitives. That last dependency is the most consequential one to notice when you read the manifest, because it means this project's behaviour is partly inherited from another tool in the same family.

The scope question is the relay capability

Of the capabilities on the feature list, most are things an operator does with credentials they already hold: discovering certificate authorities and templates, identifying misconfigurations, requesting and forging certificates, and authenticating with a certificate. Two are different in kind. One is relaying authentication to the certificate authority's web or RPC endpoints, which is the technique where an authentication exchange the operator never completed is captured and replayed to obtain a certificate as somebody else. The other is shadow credentials, which writes a credential onto an object so that later authentication succeeds without the password ever being known. Both extend an engagement beyond the credentials the tester was given. Neither is a defect; both are why the authorization warning is the first thing on the page rather than a footnote. The tool carries no target allowlist, no dry run and no scope file, so the engagement rules are the only boundary, and a reviewer should treat the relay path as the one that needs an explicit written scope before anyone runs it.

No tests in the repository, and a frozen Windows build recipe

Two structural facts sit side by side at the root of the tree. There is a spec file for a packaging tool that freezes a Python program into a standalone executable, which means the project has a Windows single-file build, and the page never mentions it, since installation is deferred entirely to the wiki. And there is no test directory. Not a small one, not a disabled one: none. For a tool that parses attacker-shaped certificate templates and template extensions from a directory, and that is offered to defenders for assessing misconfiguration, the absence of a suite in the repository means there is no regression signal for the parsing logic and no way for an outside reviewer to check the behaviour claims without reading the source. That is a decision a maintainer is entitled to make, and it is also the first thing to ask about before running it against a real directory.

Four tool configurations across two files, and no development status

The quality tooling is configured twice over. A flake8 configuration sits in its own file at the root. A Pyright configuration, which is a separate type checker from the linter, sits in another file. Inside the manifest there is a formatter configuration and an import sorting configuration, and the import sorter is explicitly set to a profile that matches the formatter so the two do not fight, with the line length written out in both. So four tools, four settings blocks, three files, with one value duplicated. The metadata classifiers are thinner than that. There are three of them: the language, the licence, and the operating system. There is no development status classifier despite the project being on its fifth major series, and no classifier naming the specific Python versions, so the only statement about interpreter support is the floor in the manifest. For a package that people pipe into audits, that is thin metadata for a mature version number.

Editorial conclusion

Certipy suits a red team operator or a defender auditing certificate services in an environment they are authorized to test, and who already has Active Directory tooling in the same toolkit family. Four things to check first. The scope question is the serious one, because among its advertised capabilities is relaying authentication the operator never had, which is a technique whose blast radius is set entirely by the engagement rules rather than by the tool. The README contains no commands, no install steps and no vulnerability detail, so everything operational lives in a wiki. Every dependency is pinned to a compatible-release range, including the cryptography library, so security updates arrive only within a major line. And there is no test directory in the repository, so read the code before you point it at a production directory.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. ly4k/Certipy on GitHub
4. README
5. Releases