Introduction Building a certificate authority (CA) for your lab environment is a pain. Until recently I relied on Jamielinux's OpenSSL Certificate Authority but it slowly lost relevance due to evolutions in Public Key Infrastructure (PKI) requirements, specifically ECC, hash, critical certificate extensions, and revokation changes. This guide adheres to current PKI needs namely RFC 5759 NSA's Suite B Certificate and Certificate Revocation List (CRL) Profile. Before you start burning effigies in the comment section, yes I know ECC curves NIST P-256 and NIST P-384 are not considered "secure" by SafeCurves related to rigidity1, ladder2, completeness3, and indistinguishability4. Modern PKI ends up being a slightly religious debate divided across admins who practice provable security versus evangelists preaching mathematically absolute cryptography. I err towards the side of practical and provable security. If we adjusted cryptological practices to comply with every cryptographic sermon, we'd have nothing left to provide our infrastructure that a reasonable number of clients could connect to; forget if my infrastructure can even support it. What Suite B does offer is compatibility with browsers and applications. Complying with popular standards allows us to learn about some of the more overlooked PKI requirements mentioned above. You don't need to fully understand the mathematical intricacies of elliptical curves but you do need to know what your applications and clients can use, especially when certain internet entities quietly drop support for unpopular curves "cough.... Chrome". So many caveats to PKI raise a question of why we're using OpenSSL and why are we building a CA compliant to NSA Suite B (specifically NIST P-384). OpenSSL is free and used by a majority of OS and application vendors. Many admins have familiarity with it's various commands My lab is in AWS and their provided Active Directory offerings do not allow us Enterprise Admin roles; a requirement for setting up Microsoft Certificate Authorities and I am not going to spin up independent AD infrastructure for isolated VPCs We learn OpenSSL commands related to elliptical curves (some of the many) We must pay attention to certificate extension attributes We must create a revocation policy which many existing guides gloss over We must pay attention to OpenSSL's caveat's and limitations to modern PKI requirements, including version support for various features. I tested this series against OpenSSL v1.0.2g (default on Ubuntu 16.04 LTS), and v1.1.0f (manual upgrade to OpenSSL current release). There are some featuers within OpenSSL I am eagerly waiting but are not available as of the current public release. I will keep updating this as requirements and feature become mainstream. This guide is not intended for the hemmoraging edge admin who lives a brazen alpha code lifestyle. Suite B PKI Requirements and CA Design Considerations This guide assists the reader to build a lab-ready CA using elliptical curves for cryptographic signatures and hash functions. RFC 5759 states: Every Suite B cert MUST use the x.509 v3 format and contain An ECDSA-capable signing key, using curves P-256 or P-384 OR An ECDH-capable key establishment key, using curve P-256 or P-384 Every Suite B certificate and CRL MUST be signed using ECDSA. The CA's (Root and Intermediary) MUST be on the curve P-256 or P-384 if the CA contains a key on the curve P-256. If the certificate contains a key on the curve P-384, the signing CA's Key MUST be on the curve P-384. Any certificate and CRL MUST be hashed using SHA-256 or SHA-384, matched to the size of the signing CA's key. Suite B PKI follows RFC5280 for marking extensions as critical and non critical. Microsoft helps distill the extension requirements to: subjectKeyIdntifier (SKI), keyUsage, and basicConstraints MUST exist keyUsage MUST be marked as critical ke