Merge pull request #1352 from inteon/move_concepts_certificate

Removing the 'concepts' > 'Certificate' page

content/docs/concepts/acme-orders-challenges.md

@@ -22,7 +22,7 @@ validation can be found on the Let's Encrypt website
 certificate request which will be created automatically once a new
 [`CertificateRequest`](../usage/certificaterequest.md) resource referencing an ACME
 issuer has been created. `CertificateRequest` resources are created
-automatically by cert-manager once a [`Certificate`](./certificate.md) resource
+automatically by cert-manager once a [`Certificate`](../usage/certificate.md) resource
 is created, has its specification changed, or needs renewal.
 
 As an end-user, you will never need to manually create an `Order` resource.

content/docs/manifest.json

@@ -791,10 +791,6 @@
                   "title": "Issuer",
                   "path": "/docs/concepts/issuer.md"
                 },
-                {
-                  "title": "Certificate",
-                  "path": "/docs/concepts/certificate.md"
-                },
                 {
                   "title": "ACME Orders and Challenges",
                   "path": "/docs/concepts/acme-orders-challenges.md"

content/docs/tutorials/acme/http-validation.md

@@ -84,7 +84,7 @@ spec:
 
 The Certificate resource describes our desired certificate and the possible
 methods that can be used to obtain it. You can learn more about the Certificate
-resource in the [docs](../../concepts/certificate.md).  If the certificate is
+resource in the [docs](../../usage/certificate.md).  If the certificate is
 obtained successfully, the resulting key pair will be stored in a secret called
 `example-com-tls` in the same namespace as the Certificate.
 

content/docs/tutorials/acme/nginx-ingress.md

@@ -237,7 +237,7 @@ when you might choose to use each can be found on [Issuer concepts](../../concep
 Certificates resources allow you to specify the details of the certificate you
 want to request. They reference an issuer to define _how_ they'll be issued.
 
-For more information, see [Certificate concepts](../../concepts/certificate.md).
+For more information, see [Certificate concepts](../../usage/certificate.md).
 
 ## Step 6 - Configure a Let's Encrypt Issuer
 

content/docs/tutorials/getting-started-with-cert-manager-on-google-kubernetes-engine-using-lets-encrypt-for-ingress-ssl/README.md

@@ -628,7 +628,7 @@ Events:
 
 When you create a Certificate, cert-manager will create a collection of temporary resources
 which each contain information about the status of certificate signing process.
-You can read more about these in the [Certificate Lifecycle](../../concepts/certificate.md#certificate-lifecycle) section.
+You can read more about these in the [Certificate Lifecycle](../../usage/certificate.md#certificate-lifecycle) section.
 Use the `cmctl status` command to view details of all these resources and all the associated Events and error messages.
 
 You may see some temporary errors, like:

content/docs/usage/README.md

@@ -11,8 +11,6 @@ Once an [`Issuer`](../configuration/README.md) has been configured, you're ready
 
 There are several use cases and methods for requesting certificates through cert-manager:
 
-- [Certificate Resources](./certificate.md): The simplest and most common method for
-  requesting signed certificates.
 - [Securing Ingress Resources](./ingress.md): A method to secure ingress resources
   in your cluster.
 - [Securing OpenFaaS functions](https://docs.openfaas.com/reference/ssl/kubernetes-with-cert-manager/):

content/docs/usage/certificate.md

@@ -128,6 +128,31 @@ The `Certificate` will be issued using the issuer named `ca-issuer` in the
 A full list of the fields supported on the Certificate resource can be found in
 the [API reference documentation](../reference/api-docs.md#cert-manager.io/v1.CertificateSpec).
 
+### Target Secret
+
+When a certificate is issued by an intermediate CA and the `Issuer` can provide
+the issued certificate's chain, the contents of `tls.crt` will be the requested
+certificate followed by the certificate chain.
+
+Additionally, if the Certificate Authority is known, the corresponding CA
+certificate will be stored in the secret with key `ca.crt`. For example, with
+the ACME issuer, the CA is not known and `ca.crt` will not exist in the Secret.
+The `ca.crt` value at the time of issuance can be copied to the trust store of
+the application that is using the certificate. However, DO NOT directly mount
+the `ca.crt` value into the application's trust store, as it will be updated
+when the certificate is renewed (see [Trusting certificates](../trust/README.md) for more details).
+
+cert-manager intentionally avoids adding root certificates to `tls.crt`, because they
+are useless in a situation where TLS is being done securely. For more information,
+see [RFC 5246 section 7.4.2](https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.2)
+which contains the following explanation:
+
+> Because certificate validation requires that root keys be distributed
+> independently, the self-signed certificate that specifies the root
+> certificate authority MAY be omitted from the chain, under the
+> assumption that the remote end must already possess it in order to
+> validate it in any case.
+
 <a id="key-usages"></a>
 ### X.509 key usages and extended key usages
 

content/docs/usage/certificaterequest.md

@@ -105,7 +105,7 @@ This condition should only be set by an approver.
 namely: `username`, `groups`, `uid`, and `extra`. These values contain the user
 who created the `CertificateRequest`. This user will be cert-manager itself in
 the case that the `CertificateRequest` was created by a
-[`Certificate`](./certificate.md) resource, or instead the user who created the
+[`Certificate`](../usage/certificate.md) resource, or instead the user who created the
 `CertificateRequest` directly.
 
 > **Warning**: These fields are managed by cert-manager and should _never_ be

content/docs/usage/ingress.md

@@ -102,7 +102,7 @@ trigger Certificate resources to be automatically created:
   This annotation will also add the annotation
   `"cert-manager.io/issue-temporary-certificate": "true"` onto created
   certificates which will cause a [temporary
-  certificate](./certificate.md#temporary-certificates-whilst-issuing) to be set
+  certificate](../usage/certificate.md#temporary-certificates-whilst-issuing) to be set
   on the resulting Secret until the final signed certificate has been returned.
   This is useful for keeping compatibility with the `ingress-gce` component.
 

public/_redirects

@@ -221,6 +221,7 @@ https://docs.cert-manager.io/* https://cert-manager.io/docs/:splat 302!
 
 # Moved the concept pages into the main website
 /docs/concepts/certificaterequest/ /docs/usage/certificaterequest/ 301!
+/docs/concepts/certificate/ /docs/usage/certificate/ 301!
 
 # Moved the external issuer section to the main issuers page
 /docs/configuration/external/ /docs/configuration/issuers/ 301!