<p>I generated a private key and and a new certificate from SSL.com and now I want to use these to sign the certificates in my Kubernetes cluster. I followed the below method to create the new issuer.</p>
<p><a href="https://cert-manager.io/docs/configuration/ca/" rel="nofollow noreferrer">https://cert-manager.io/docs/configuration/ca/</a></p>
<p>Once I create the new issuer, it gives an error. Any help would be appreciated. Below is the error message.</p>
<pre><code>Events:
  Type     Reason             Age                From          Message
  ----     ------             ----               ----          -------
  Warning  ErrInvalidKeyPair  17m (x2 over 17m)  cert-manager  Error getting keypair for CA issuer: certificate is not a CA
</code></pre>

Dusty
<p>CA certificates have a <strong>basicConstraint</strong> extension which is set to <strong>CA:True</strong>.  Your normal, run of the mill, end-entity certificate does not have this extension set as above, which is why you are seeing this error.  That is, you cannot sign other certificates with an end-entity certificate's private key.</p>
<p>This is by design.  A CA is required to certify that the holder of the certificate is who/what they are.  They cannot delegate that responsibility to a user who's carried out minimal authentication and simply paid a few dollars/euros/rubles for a certificate.  If they permitted this and issued CA certificates to every subscriber, then anyone and everyone could issue themselves certificates that claimed to be from your bank, or from Google etc.  - the security of the Internet would soon fail.</p>
<p>Your options are limited:</p>
<ol>
<li>Find a commercial CA who allows you to issue your own certificates - this is likely to be prohibitively expensive and would involve regular auditing of your extensive processes and procedures.</li>
<li>Operate your own private PKI - you can do whatever you want with this.  Do bear in mind that external users would not trust this and you would need to persuade others that your PKI is trustworthy.  Depending on the size and security stance of your user base, this may also entail defining extensive processes and procedures and regular auditing of those to ensure you PKI remains trustworthy to your users.</li>
</ol>
