cloudflare / origin-ca-issuer Goto Github PK

View Code? Open in Web Editor NEW

226.0 10.0 60.0 151 KB

cert-manager issuer for Origin CA

License: BSD 3-Clause "New" or "Revised" License

Go 92.94% Smarty 2.19% Makefile 4.16% Dockerfile 0.71%

origin-ca-issuer's People

Contributors

Stargazers

Watchers

Forkers

yutori abhi1693 mfkbot shinofara sashamarrocco chriseke joshvanl ajayk mashbrno cubitoom cyberflamego mcdermg monoclue ctholho cemberk akauper runako ngeorger alex77g hkk97 simonrosenau rlmsco bchrobot isabella232 kalinaladnay sidineyc aliexa advatys sbw210 sgran michithan wadells startupfuture abdymazhit catarse sf9040 pkrishnath icodein bharathkumarraju letschurch itay-grudev therealdwright caffeelake paulsinai syseleven heffcodex automatiq-team annihilatopia alt-research sredevopsorg alphyriver bsgrigorov brydenver2 youtacrands-va penumbra23 rohankumardubey beyondaman youtac-resources-and-services 0xgoerlimainnet

origin-ca-issuer's Issues

Getting full chain in certificate

Hi,

do you think if it would make sense to offer a CRD flag to include full chain in auto-created certificate?

I noticed issues by serving created certificates to clients: curl: (60) SSL certificate problem: unable to get local issuer certificate. I guess because there is no full chain included.

Cheers!

Edit: If those are certificates used only to work behind CF proxies, then I probably missed the point. We are trying to use them for internal networking, not going over CF. Domains are, of course, managed in CF. Well, I think I've missed this: "You'll be able to use this certificate on servers proxied behind Cloudflare." — CF blog.

Invalid value "OriginIssuer"

With cert-manager in version v1.10.0 cert-manager-controller throws the following error, certs are successfully issued though.
The issuerRef.kind requirements have changed.

E1031 19:23:01.329393 1 checks.go:95] cert-manager/controller/certificaterequests-issuer-selfsigned/handleSecretReference "msg"="failed to get issuer" "error"="invalid value \"OriginIssuer\" for issuerRef.kind. Must be empty, \"Issuer\" or \"ClusterIssuer\"" "resource_kind"="Secret" "resource_name"="server37-k9rtd" "resource_namespace"="default" "resource_version"="v1"

invalid header field value "...." for key X-Auth-User-Service-Key

Issue

I've deployed the helm chart that is published at https://cloudflare.github.io/origin-ca-issuer/charts with basically default values after I setup the CRDS. The origin Issuer is ready.

│ Status:                                                                                                                                                                                                                                    
│   Conditions:                                                                                                                                                                                                                              
│     Last Transition Time:  2023-07-21T15:22:54Z                                                                                                                                                                                            
│     Message:               OriginIssuer verified and ready to sign certificates                                                                                                                                                            
│     Reason:                Verified                                                                                                                                                                                                        
│     Status:                True                                                                                                                                                                                                            
│     Type:                  Ready                                                                                                                                                                                                           
│ Events:                    <none>

But the api is telling me the key being provided is an invalid value. I can use that token locally to create certs so I'm not sure what the issue is but could it be the extra new line character in the error returned by the api that is showing up in the logs? I've confirmed this is not present in the secret.

Logs

Cert Request event

The certificate request has failed to complete and will be retried: Failed to sign certificate request: unable to sign request: Post "https://api.cloudflare.com/cl │
│ ient/v4/certificates": net/http: invalid header field value "v1.0-fffff-fffffff │
│ f87\n" for key X-Auth-User-Service-Key

Origin CA Issuer Deployment Logs:

cloudflare-origin-ca-issuer-6dcb4bb644-sxgdn {"level":"error","error":"unable to sign request: Post \"https://api.cloudflare.com/client/v4/certificates\": net/http: invalid header field value \"v1.0-ffff-fffffffffffff\\n\" for key X-Auth-User-Service-Key","name":"origin-issuer/controllers/CertificateRequest","certificaterequest":{"Namespace":"cert-manager","Name":"domain-com-6xtps"},"time":"2023-07-21T15:54:48Z","message":"failed to sign certificate request 

cloudflare-origin-ca-issuer-6dcb4bb644-sxgdn {"level":"error","error":"unable to sign request: Post \"https://api.cloudflare.com/client/v4/certificates\": net/http: invalid header field value \"v1.0-ffff-ffffffffffffffffffff\\n\" for key X-Auth-User-Service-Key","name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"domain-com-6xtps","namespace":"cert-manager","time":"2023-07-21T15:54:48Z","message":"Reconciler error"}

Using the published helm chart 0.5.0 which is origin-ca-issuer version 0.6.1

Publish Docker image

Now that we're open source (🥳), it's time to get an image pushed to Docker Hub, and the deployment manifests updated to match.

Missing role permissions

Creating the clusterole with rolebinding I can see there following errors on startup:

E1227 12:58:29.434870       1 reflector.go:127] k8s.io/[email protected]/tools/cache/reflector.go:156: Failed to watch *v1.CertificateRequest: failed to list *v1.CertificateRequest: certificaterequests.cert-manager.io is forbidden: User "system:serviceaccount:network:default-origin-ca-issuer" cannot list resource "certificaterequests" in API group "cert-manager.io" at the cluster scope

Which I've validated with SA impersonation

❯ k auth can-i list certificaterequests --as=system:serviceaccount:network:default-origin-ca-issuer
no

origin-ca-issuer/deploy/charts/origin-ca-issuer/templates/issuer-clusterrole.yaml

Line 20 in 9b5ebe0

- apiGroups: ["cert-manager.io"]

API Token instead of CA key

I know this has been asked and answer before. Is there still plans to support the use of API Token instead of CA Key. Thank you.

Feature: Edge cert creation parrallel to origin cert creation.

Pretty much the title. From what I can understand this only creates origin certs. Is it possible to create edge certs for each origin cert created?

Multi-cluster kubernetes deployment

Hello,

I have a multi-cluster infrastructure, with cert-manager on each cluster. I would like to produce a certificate for the same domain on all clusters.

So basically when time comes for the renewal, all clusters will make a request for the same domain.

I would like to know if this is possible. For example this is not possible with let's encrypt issuer since it rate limits duplicate requests for the same domain to 5, so when time comes to renew, if you have more than 5 clusters, you will be rate limited as each cluster will make a separate request.

I just wanted to know if there is a similar rate limit.

Thanks a lot.

Unable to issue certificates for ingress

There are two issues:

I've followed the readme, but it's unable to find prod-issuer. I've tried to place it in default namespace as well as in origin-ca-issuer with no success.
The ingress is requesting secretName tls-admintool, but there are attempts to generate tls-admintool-bqrd6 with some random suffix. Such secrets won't match and ingress will not work.

origin-ca-controller
{"level":"error","error":"OriginIssuer.cert-manager.k8s.cloudflare.com \"prod-issuer\" not found","name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"tls-admintool-bqrd6","namespace":"data3s-cz-test","time":"2021-05-25T19:30:25Z","message":"Reconciler error"}

Helm repo not available

Hi folks, we are trying to use terraform to install the origin-ca-issuer into a kubernetes cluster but we were not able to identify the remote repo to pass to the next command:

helm repo add origin-ca-issuer

Do you happen to know if it is possible to install it with the command above or we have to download the repo and then run helm install?

Thank you in advance

cert-manager templated value breaks helm installation

Hi,

Looks like this commit is missing templates in helpers

Error at Helm install:

reconciliation failed: Helm install failed: template: origin-ca-issuer/templates/issuer-rolebinding.yaml:41:20: executing "origin-ca-issuer/templates/issuer-rolebinding.yaml" at <{{template "cert-manager.serviceAccountName" .}}>: template "cert-manager.serviceAccountName" not defined

Publish Helm Chart with Github Pages

It would be great to host the helm charts and have them published.

This is primarily useful for automation tools where users may use helm repositories to integrate with tools such as Flux(v1/v2) and ArgoCD. It also allows for ease of semantic versioning of your chart releases and easy rollbacks during remediation for users when newer releases introduce breaking changes and is a little cleaner than depending on a git source and using a release/branch.

Incorrect indentation for resources

Rendering the template and then running --dry-run will highlight that the resource limits and requests are not sufficiently indented, I've manually fixed this locally however this should be fixed in the chart.

origin-ca-issuer/deploy/charts/origin-ca-issuer/templates/issuer-deployment.yaml

Line 75 in 04d9397

resources: {{ toYaml .Values.controller.resources | nindent 8 }}

Multiple Domain support

Hello, I just wanted to reach out I am trying to get multiple domain support working,

I have 2 domains in Cloudflare:

example.app
example.onl

my ingress's

hello.example.app, hello.test.example.app => hello-service
hello.example.onl => hello-service

When I apply the ingress config I have tried 1 ingress with 3 rules/tls blocks, I have tried 2 separate ingress resources for each domain

the example.app ingress I have for the 2 hello subdomains that one works and routes accordingly to the hello service I get the webpage all is fine (both URL's), I check Cloudflare I have 2 origin certificates in the correct domain, the dns records are orange proxied, pointed to my nginx ingress LB everything is great there.

The ingress definition for hello.example.onl to the other domain it also creates an origin server in the correct zone but when going to the URL I get ERR_TOO_MANY_REDIRECTS error in chrome the dns record for this one is proxied (orange proxy icon), the only difference between the 2 ingress definitions is the domain url, they both use the same OriginIssuer the api key for the OriginIssuer has access to both zones as it does create the origin certs in both the respective zones.

RBAC issue in chart

E0602 22:58:55.149597       1 controller.go:158] cert-manager/controller/certificaterequests-approver "msg"="re-queuing item due to error processing" "error"="admission webhook \"webhook.cert-manager.io\" denied the request: status.conditions: Forbidden: user \"system:serviceaccount:networking:cert-manager\" does not have permissions to set approved/denied conditions for issuer {cloudflare-issuer OriginIssuer cert-manager.k8s.cloudflare.com}" "key"="networking/traefik-dashboard-crt-f4mc7

quay.io/jetstack/cert-manager-controller:v1.3.1

cloudflare/origin-ca-issuer:v0.6.0

helm versions

cert-manager     v1.3.1  
origin-ca-issuer v0.5.0

Feature: ClusterOriginIssuer support or cross namespace referencing

A feature I'd like to see is to be able to create a cluster scoped ClusterOriginIssuer resource that my Certificates can reference.

At present the OriginIssuer seems to need to be present in the same namespace that the Certificate is located in.

For example, I'm using istio and running my ingress-gateway in the istio-system namespace, therefore i'm going to create my Certificate resource in this namespace, however, I've deployed origin-ca-issuer with the OriginIssuer into my network namespace.

{"level":"error","error":"OriginIssuer.cert-manager.k8s.cloudflare.com \"prod-issuer\" not found","name":"origin-issuer/controllers/CertificateRequest","certificaterequest":{"Namespace":"istio-system","Name":"raspbernetes-com-zt9wv"},"namespace":"istio-system","name":"prod-issuer","time":"2021-01-12T00:11:13Z","message":"failed to retrieve OriginIssuer resource"}

failed to sign certificate request - error parsing time

Hello .

I am getting this error while trying to sign a certificate :

default 0s Warning Failed certificate/example-com The certificate request has failed to complete and will be retried: Failed to sign certificate request: unable to sign request: parsing time "" as "2006-01-02T15:04:05Z07:00": cannot parse "" as "2006"

The originissuer and everything is in place as per installation instructions :

kubectl get originissuer.cert-manager.k8s.cloudflare.com prod-issuer -n default -o json | jq .status.conditions
[
{
"lastTransitionTime": "2021-11-25T13:27:32Z",
"message": "OriginIssuer verified and ready to sign certificates",
"reason": "Verified",
"status": "True",
"type": "Ready"
}
]

The issue seems to be related to this :

cloudflare/cloudflare-go#190

My setup :

cert-manager-v1.5.4
kubernetes : v1.21.5
origin-ca-issuer : cloudflare/origin-ca-issuer:v0.6.0

Helm Chart general improvements

The issues are:

The chart doesn't include the CRDs definitions, this can be done by adding the definitions under crds directory. More info can be found here
If one doesn't want to include the CRDs automatically is just about setting --skip-crds flag
As mentioned on #45 , the chart just assumes the namespace and also the service account name used by cert-manager, that is not always the case.

Make cert-manager serviceAccount configurable in Helm Chart

Cert-manager might not be installed under the default name or namespace so the serviceAccount that is used in the clusterRoleBinding should be configurable.

Errors installing the controller

Kubernetes v1.19.4
Cert-manager v1.0.4

$ kubectl apply -f deploy/manifests --validate=false
unable to recognize "deploy/manifests/serviceaccount.yaml": no matches for kind "SeriveAccount" in version "v1"
Error from server (Invalid): error when creating "deploy/manifests/deployment.yaml": Deployment.apps "origin-ca-issuer" is invalid: [spec.template.metadata.labels: Invalid value: map[string]string(nil): `selector` does not match template `labels`, spec.template.spec.containers: Required value]

unexpected dash breaks helm installation

This commit uses wrong helm syntax and breaks existing helm installation.

jq .status.conditions returns null after following the README steps

Following the steps in the README gives me null when running the below command.

kubectl get originissuer.cert-manager.k8s.cloudflare.com prod-issuer -o json | jq .status.conditions

If I remove the jq part I get this response.

{
    "apiVersion": "cert-manager.k8s.cloudflare.com/v1",
    "kind": "OriginIssuer",
    "metadata": {
        "annotations": {
            "kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"cert-manager.k8s.cloudflare.com/v1\",\"kind\":\"OriginIssuer\",\"metadata\":{\"annotations\":{},\"name\":\"prod-issuer\",\"namespace\":\"default\"},\"spec\":{\"auth\":{\"serviceKeyRef\":{\"key\":\"key\",\"name\":\"service-key\"}},\"requestType\":\"OriginECC\"}}\n"
        },
        "creationTimestamp": "2022-01-24T15:58:14Z",
        "generation": 1,
        "name": "prod-issuer",
        "namespace": "default",
        "resourceVersion": "1845",
        "uid": "63093b88-ca0f-45f0-b832-12b9a5489963"
    },
    "spec": {
        "auth": {
            "serviceKeyRef": {
                "key": "key",
                "name": "service-key"
            }
        },
        "requestType": "OriginECC"
    }
}

I did generate secret etc as described in the readme.

planned support for ClusterIssuer ?

Hello .

Is there any support or planned support for ClusterIssuer kind ?

We're looking to send requests from different namespaces without deploying the OriginIssuer and key in each namespace and wonder if this will be supported .

Thanks .

Helm Chart fails when cert-manager runs in different namespace

If you look at this file:
https://github.com/cloudflare/origin-ca-issuer/blob/trunk/deploy/charts/origin-ca-issuer/templates/issuer-rolebinding.yaml

It assumes that cert-manager is running in the cert-manager namespace which isn't always the case.

Failed to sign certificate request: unable to sign request: Cloudflare API Error code=1016

Getting the following error:

Failed to sign certificate request: unable to sign request: Cloudflare API Error code=1016 message=User is not authorized to perform this action

When requesting a certificate through kubernetes ingress.

I believe this may be due to the zone_id parameter not being included in api requests.

For reference the full certificate status

Name: some-cert
Namespace: default
Created at: 2022-07-12T16:11:28+01:00
Conditions:
  Issuing: False, Reason: Failed, Message: The certificate request has failed to complete and will be retried: Failed to sign certificate request: unable to sign request: Cloudflare API Error code=1016 message=User is not authorized to perform this action
  Ready: False, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
DNS Names:
- dev.example.com
Events:
  Type     Reason     Age                  From          Message
  ----     ------     ----                 ----          -------
  Normal   Generated  23m                  cert-manager  Stored new private key in temporary Secret resource "some-cert-dt6vh"
  Normal   Requested  23m                  cert-manager  Created new CertificateRequest resource "some-cert-fh5tw"
  Normal   Issuing    2m39s (x2 over 23m)  cert-manager  Issuing certificate as Secret does not exist
  Warning  Failed     2m38s (x2 over 23m)  cert-manager  The certificate request has failed to complete and will be retried: Failed to sign certificate request: unable to sign request: Cloudflare API Error code=1016 message=User is not authorized to perform this action
  Normal   Generated  2m38s                cert-manager  Stored new private key in temporary Secret resource "some-cert-4rfkj"
  Normal   Requested  2m38s                cert-manager  Created new CertificateRequest resource "some-cert-vl5kx"
The OriginIssuer "cloudflare" is not of the group cert-manager.io, this command currently does not support third party issuers.
To get more information about "cloudflare", try 'kubectl describe'
error when finding Secret "some-cert": secrets "some-cert" not found
Not Before: <none>
Not After: <none>
Renewal Time: <none>
CertificateRequest:
  Name: some-cert-vl5kx
  Namespace: boss
  Conditions:
    Approved: True, Reason: cert-manager.io, Message: Certificate request has been approved by cert-manager.io
  Ready: False, Reason: Failed, Message: Failed to sign certificate request: unable to sign request: Cloudflare API Error code=1016 message=User is not authorized to perform this action
  Events:
    Type    Reason           Age    From          Message
    ----    ------           ----   ----          -------
    Normal  cert-manager.io  2m38s  cert-manager  Certificate request has been approved by cert-manager.io

Honour cert-manager Approval conditions

FEATURE REQUEST

fully-automated approve/deny crd for cloudflare issuer running in cert manager-managed clusters

WHY

increase ease of pki management with cloudflare and k8s clusters
other issuers like aws and google are doing so

Helm chart

Any plans to provide a Helm chart?

This would greatly simplify automated deployment.

Doesn't check for existing certificates

Hello,

I've been using for 2 weeks or so this origin-ca-issuer for staging purposes where we have automatic deployments being done.
Today I had to create an origin certificate manually and when I checked, we actually had over 8000 certificates, and about 5000 or so of those were all actually from a single subdomain.
I'm not sure what the hell happened, still trying to debug the situation but one thing seems to be wierd, shouldn't origin-ca-issuer before issueing a new certificate check if there isn't one already for that exact same subdomain? and if so re-use it?

Thanks,
João Lourenço

403 when using origin-ca-issuer

Hey!

So, I have a k8s cluster on digital ocean and I'm using origin-ca-issuer to have the certificates from cloudflare on my k8s cluster.
I've set it up but it seems something is failing but I can't quite figure out what and I've ran out of ideas to look into.

Basically I have created my ingress as follows:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: text-ingress
  namespace: default
  annotations:
    # nginx
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    # nginx.ingress.kubernetes.io/ssl-passthrough: "true"
    nginx.ingress.kubernetes.io/proxy-ssl-name: "test.stagging.mydomain.com"

    # ssl certificate
    cert-manager.io/issuer: prod-issuer
    cert-manager.io/issuer-kind: OriginIssuer
    cert-manager.io/issuer-group: cert-manager.k8s.cloudflare.com

    # dns record
    external-dns.alpha.kubernetes.io/hostname: test.stagging.mydomain.com
    external-dns.alpha.kubernetes.io/ttl: "1"
    external-dns.alpha.kubernetes.io/cloudflare-proxied: "true"
spec:
  rules:
    - http:
        paths:
          - pathType: Prefix
            path: /
            backend:
              service:
                name: nginx
                port:
                  number: 80
      host: test.stagging.mydomain.com
  tls:
    - hosts:
        - test.stagging.mydomain.com
      secretName: test-stagging-mydomain-com-tls

What happens is, if I have on cloudflare proxy enabled I get the typical 403 black/white screen, and if I turn it off it works nicely.
I'm thinking its some issue on the certs as when I check them on my browser they are expired somehow...

More over, when I check my Certificate and my Orders on my cluster it all seems nice without any errors and it says it's valid.

Any ideas would be greatly appreciated.

add installCRDs as option in helm chart

would be neat for easy automated installation 🤷

Helm Chart inaccessible

Love this project, but seems like the helm chart repository is no longer working? Is it possible to fix it?

Nginx controller warns about expiring certificate

Is there any option to prolong certificate validity or set the validity threshold on nginx ingress controller? Currently it warns every 3 minutes:

SSL certificate for server "example.com" is about to expire (2021-06-02 07:45:00 +0000 UTC)

per nginx pod per issued certificate.

Revoke old Origin Certificates

Hi,

Is there a way/an opt to revoke expired certificates via origin-ca-issuer?
As an example I have an Ingress Certificate which is responsible for my origin certificates;

Certificates Screenshot

Failed to sign certificate request: unable to sign request: invalid character 'e' looking for beginning of value

Working through installing this and this is the message in the certificaterequest/ that shows up.

What would be the next step in getting this working?

x509: certificate signed

$ kubectl logs origin-ca-issuer-55484d5db6-xmcnn -n origin-ca-issuer

{"level":"error","error":"unable to sign request: Post \"https://api.cloudflare.com/client/v4/certificates\": x509: certificate signed by unknown authority","name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"mfkasia-tls-hr67n","namespace":"hoge","time":"2020-12-18T03:03:38Z","message":"Reconciler error"}

Is this a CA certificate old problem?

OOMkill pod memory limits

Pod memory limits seem a little low, had to bump in my cluster to get the pods to come up. or else they were crashing on startup running out of memory

API Token instead of CA key

Hi there.

As I understand the API Token isn't supported at the mom and the recommended usage is origin ca keys. However, I'd like to know if there's any workaround in case I cannot use the ca key due to the company's policy?

Many thanks,
T.

Failed to sign certificate request: unable to sign request: Cloudflare API Error code=1016

Getting error:

secret for certificate has only tls.key and with Full (strict) mode I see 526 error

Hey. Was using LE for my Origin certs, decided to move to CF's certificates. Installed everything as in manual, using ingresses annotations to create SSL cert, but instead, the full cert secret has only tls.key and in the Strict mode CF shows me 526 error. Cert issuer and ingress are in the same namespace, issuer tells me it is ready (as in the manual). What might be wrong?
Origin CA key is correct, secret is in place.

The condition of originissuer.cert-manager.k8s.cloudflare.com does not become Redy.

I see the README.
I can't proceed because the condition of originissuer.cert-manager.k8s.cloudflare.com doesn't exist.

$ kubectl get originissuer.cert-manager.k8s.cloudflare.com prod-issuer -o json -n hoge | jq .status.conditions
<empty>

$ kubectl get originissuer.cert-manager.k8s.cloudflare.com prod-issuer -o json -n hoge | jq .
{
  "apiVersion": "cert-manager.k8s.cloudflare.com/v1",
  "kind": "OriginIssuer",
  "metadata": {
    "annotations": {
      "kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"cert-manager.k8s.cloudflare.com/v1\",\"kind\":\"OriginIssuer\",\"metadata\":{\"annotations\":{},\"name\":\"prod-issuer\",\"namespace\":\"hoge\"},\"spec\":{\"auth\":{\"serviceKeyRef\":{\"key\":\"key\",\"name\":\"service-key\"}},\"requestType\":\"OriginECC\"}}\n"
    },
    "creationTimestamp": "2020-12-17T14:32:21Z",
    "generation": 2,
    "name": "prod-issuer",
    "namespace": "hoge",
    "resourceVersion": "58522222",
    "selfLink": "/apis/cert-manager.k8s.cloudflare.com/v1/namespaces/hoge/originissuers/prod-issuer",
    "uid": "9073f00b-d7ce-40f4-ba02-207bedc16e2e"
  },
  "spec": {
    "auth": {
      "serviceKeyRef": {
        "key": "key",
        "name": "service-key"
      }
    },
    "requestType": "OriginECC"
  }
}

Where should I look? Or if there is a solution, please let me know.

publish helm charts

I am trying to set up Origin CA Issuer automatically using Terraform. The problem I have is that you need to clone the repository to install it.

It would be very simple to do if the yaml files in each step were combined into a single file. That way you can apply it using the raw github url, like with the CRDs: kubectl apply -f https://raw.githubusercontent.com/cloudflare/origin-ca-issuer/trunk/deploy/crds/cert-manager.k8s.cloudflare.com_originissuers.yaml

It would also be nice if something like https://github.com/helm/chart-releaser-action was used to publish the helm chart.

OriginRSA and OriginECC are flipped?

Take a look at

origin-ca-issuer/pkgs/provisioners/origin.go

Lines 108 to 111 in 39d567a

    
           case v1.RequestTypeOriginECC: 
        
           	reqType = "origin-rsa" 
        
           case v1.RequestTypeOriginRSA: 
        
           	reqType = "origin-ecc"

I just installed origin-ca-issuer (it works great!), but I noticed I got a SHA256-RSA signature when using the OriginIssuer example from the README, which sets requestType: OriginECC.

Conversely, when I updated it to requestType: OriginRSA and forced a certificate to be reissued, I got a ECDSA-SHA256 signature.

Option to install the OriginIssuer CRD automatically with the Helm chart

Can we add an option to install the OriginIssuer CRD automatically with the Helm chart?

It can be done with a custom option like cert-manager's installCRDs option? It could be false by default for backwards compatibility (like cert-manager).

It would just require one manual step less and would allow to install this as a subchart. (See #77).

Are PRs accepted for this change?

I would be grateful if you could create a tag: 0.5.1 tag.

Thank you for solving the problem.
#12

I would be grateful if you could create a tag: 0.5.1 tag.
I want to use new image

unable to get local issuer certificate

Hi, guys, first of all thanks for creating this extension for cert-manager.

I'm having an issue with certificate verification after successful installation of origin-ca-issuer by Cloudflare. So, I configured origin-ca-issuer to work with cert-manager and it issues Cloudflare certificates without any problem, but when I send requests to server either with curl or other software, certificate can't get verified for some reason. The only workaround I found so far, was to include Cloudflare's Origin CA root certificate in each request.

Error from curl:

curl: (60) SSL certificate problem: unable to get local issuer certificate

When I bypass verification using -k flag on curl, certificate issuer is correct:

issuer: C=US; O=CloudFlare, Inc.; OU=CloudFlare Origin SSL Certificate Authority; L=San Francisco; ST=California

Can you suggest something or how to deal with this issue ?

CertificateRequest is not getting approved

I have tried installing it through the deployment manifests through kubectl apply and also through the helm chart, but I cannot seem to get the CertificateRequest approved.
I tried deleting and reapplying the certificate to get it to approve but it is not working. I got all the RBAC manifests applied as well.

Any ideas I could try to get it working?

Went through README, certificate request isn't showing any events or populating the cert

So I setup the secret using our API key.

kubectl create secret generic \
-n palolo-alpha service-key \
--from-literal key=v1.0-look-it-up-in-cloudflare-origin-api-key -oyaml

apiVersion: v1
data:
  key: [redacted]
kind: Secret
metadata:
  creationTimestamp: "2022-04-21T20:37:38Z"
  name: service-key
  namespace: palolo-alpha
  resourceVersion: "1837787"
  uid: 5ec2ec02-bce3-421e-88a2-cae41ba55e2c
type: Opaque

Then I configured our issuer and certificate.

---
# Source: palolo-app/templates/certificate.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: palolo-com
  namespace: palolo-alpha
spec:
  # The secret name where cert-manager should store the signed certificate
  secretName: palolo-com-tls
  dnsNames:
    - palolo.com
    - "*.palolo.com"
  # Duration of the certificate
  duration: 168h
  # Renew a day before the certificate expiration
  renewBefore: 24h
  # Reference the Origin CA Issuer you created above, which must be in the same namespace.
  issuerRef:
    group: cert-manager.k8s.cloudflare.com
    kind: OriginIssuer
    name: prod-issuer
---
# Source: palolo-app/templates/originissuer.yaml
apiVersion: cert-manager.k8s.cloudflare.com/v1
kind: OriginIssuer
metadata:
  name: prod-issuer
  namespace: palolo-alpha
spec:
  requestType: OriginECC
  auth:
    serviceKeyRef:
      name: service-key
      key: key

And then the issuer worked.

meyerkev@ip-192-168-50-38 kubernetes % kubectl get -n palolo-alpha originissuer.cert-manager.k8s.cloudflare.com prod-issuer -o json | jq .status.conditions
[
  {
    "lastTransitionTime": "2022-04-21T20:28:30Z",
    "message": "OriginIssuer verified and ready to sign certificates",
    "reason": "Verified",
    "status": "True",
    "type": "Ready"
  }
]

But the certificate isn't showing up

meyerkev@ip-192-168-50-38 kubernetes % kubectl get -A certificate
NAMESPACE      NAME             READY   SECRET           AGE
palolo-alpha   palolo-com-tls   False   palolo-com-tls   2m25s
meyerkev@ip-192-168-50-38 kubernetes % kubectl describe -A certificate
Name:         palolo-com-tls
Namespace:    palolo-alpha
Labels:       app.kubernetes.io/instance=palolo-app
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=palolo-app
              app.kubernetes.io/version=0.1.0
              helm.sh/chart=palolo-app-0.1.0
Annotations:  <none>
API Version:  cert-manager.io/v1
Kind:         Certificate
Metadata:
  Creation Timestamp:  2022-04-21T20:28:29Z
  Generation:          1
  Managed Fields:
    API Version:  cert-manager.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          .:
          f:app.kubernetes.io/instance:
          f:app.kubernetes.io/managed-by:
          f:app.kubernetes.io/name:
          f:app.kubernetes.io/version:
          f:helm.sh/chart:
        f:ownerReferences:
          .:
          k:{"uid":"cb3bb9a5-d801-4de1-a910-506ef77444e2"}:
            .:
            f:apiVersion:
            f:blockOwnerDeletion:
            f:controller:
            f:kind:
            f:name:
            f:uid:
      f:spec:
        .:
        f:dnsNames:
        f:issuerRef:
          .:
          f:group:
          f:kind:
          f:name:
        f:secretName:
      f:status:
        .:
        f:conditions:
        f:nextPrivateKeySecretName:
    Manager:    controller
    Operation:  Update
    Time:       2022-04-21T20:28:30Z
  Owner References:
    API Version:           extensions/v1beta1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  Ingress
    Name:                  palolo-app
    UID:                   cb3bb9a5-d801-4de1-a910-506ef77444e2
  Resource Version:        1836190
  UID:                     bbd43de6-642d-4dc2-8b72-a7be092b4e2e
Spec:
  Dns Names:
    palolo.local
  Issuer Ref:
    Group:      cert-manager.k8s.cloudflare.com
    Kind:       OriginIssuer
    Name:       prod-issuer
  Secret Name:  palolo-com-tls
Status:
  Conditions:
    Last Transition Time:        2022-04-21T20:28:29Z
    Message:                     Issuing certificate as Secret does not exist
    Reason:                      DoesNotExist
    Status:                      True
    Type:                        Issuing
    Last Transition Time:        2022-04-21T20:28:29Z
    Message:                     Issuing certificate as Secret does not exist
    Reason:                      DoesNotExist
    Status:                      False
    Type:                        Ready
  Next Private Key Secret Name:  palolo-com-tls-vxdcl
Events:
  Type    Reason     Age    From          Message
  ----    ------     ----   ----          -------
  Normal  Issuing    2m32s  cert-manager  Issuing certificate as Secret does not exist
  Normal  Generated  2m31s  cert-manager  Stored new private key in temporary Secret resource "palolo-com-tls-vxdcl"
  Normal  Requested  2m31s  cert-manager  Created new CertificateRequest resource "palolo-com-tls-8qvb8"

And then the certificate request gets stuck and doesn't do anything? Events: none

meyerkev@ip-192-168-50-38 kubernetes % kubectl describe -A certificaterequest
Name:         palolo-com-tls-8qvb8
Namespace:    palolo-alpha
Labels:       app.kubernetes.io/instance=palolo-app
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=palolo-app
              app.kubernetes.io/version=0.1.0
              helm.sh/chart=palolo-app-0.1.0
Annotations:  cert-manager.io/certificate-name: palolo-com-tls
              cert-manager.io/certificate-revision: 1
              cert-manager.io/private-key-secret-name: palolo-com-tls-vxdcl
API Version:  cert-manager.io/v1
Kind:         CertificateRequest
Metadata:
  Creation Timestamp:  2022-04-21T20:28:30Z
  Generate Name:       palolo-com-tls-
  Generation:          1
  Managed Fields:
    API Version:  cert-manager.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .:
          f:cert-manager.io/certificate-name:
          f:cert-manager.io/certificate-revision:
          f:cert-manager.io/private-key-secret-name:
        f:generateName:
        f:labels:
          .:
          f:app.kubernetes.io/instance:
          f:app.kubernetes.io/managed-by:
          f:app.kubernetes.io/name:
          f:app.kubernetes.io/version:
          f:helm.sh/chart:
        f:ownerReferences:
          .:
          k:{"uid":"bbd43de6-642d-4dc2-8b72-a7be092b4e2e"}:
            .:
            f:apiVersion:
            f:blockOwnerDeletion:
            f:controller:
            f:kind:
            f:name:
            f:uid:
      f:spec:
        .:
        f:issuerRef:
          .:
          f:group:
          f:kind:
          f:name:
        f:request:
    Manager:    controller
    Operation:  Update
    Time:       2022-04-21T20:28:30Z
  Owner References:
    API Version:           cert-manager.io/v1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  Certificate
    Name:                  palolo-com-tls
    UID:                   bbd43de6-642d-4dc2-8b72-a7be092b4e2e
  Resource Version:        1836191
  UID:                     72256011-2ac4-4c42-881c-37fb93c26a69
Spec:
  Issuer Ref:
    Group:  cert-manager.k8s.cloudflare.com
    Kind:   OriginIssuer
    Name:   prod-issuer
  Request:  LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ2ZEQ0NBV1FDQVFBd0FEQ0NBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQU8ydgpUSDlmdDh3Tlh1bTlnbnd1M2p5bmc0ZmxhLzhlUHJuNVg5YWFNU3VRS2dTdkQ2ZUdNSkgxYk1hZTZ1Mjl6TnVUCi96WU9INnhIOFQyNTNpK0FKREJrQ25tSjF0cHdqQkJtNnNaZHRXWTdYekQrR1dzemFRdDJRL3BUVGdqcHRPZ00KZFcvbWdpb3ZJUjRIUzF5dEZOM1gyNm52QVhLKy9tdDZjNXgwWlN0QkdSdzNpbGI4VUFTMmlXU2lyUzdwdEEvagpOT3kzOUxKdUgzS01lMnVPQ2l0RzJCZld5K05EK2RKNUZkL2UyMTNmQVRjRStaL2k2Q3VJTFU2Z0RsR1o4NlZtCjN0UkF0ZTJrcWpkR094Y1VwLzZNUXAzWjVDVmc2blpzZ2VlbGkyL29DYlFERXhEa0ppNTIyMW5iVlpRSEdHZkEKUVZhZEp5UEVGU3ozZDFxOEJBc0NBd0VBQWFBM01EVUdDU3FHU0liM0RRRUpEakVvTUNZd0Z3WURWUjBSQkJBdwpEb0lNY0dGc2IyeHZMbXh2WTJGc01Bc0dBMVVkRHdRRUF3SUZvREFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBCml6YXBlTStWSEJ6OEx4VGJPQjhDRXpPOE5SWTlQVWZuTzBqY1JEVlpsMTBRZmZuWDFWeURWdFJMN2p6VWIvK2UKRk5zcHh0MStRUytvWkpSb0JrVDVQK2kwOVdsZkovRlhHVnBhdEl0eHp3L3llTDc5NDd2QmlZQWEyZUwyN3k2LworMzgvM0puZm8wZWk2M2d1cDhoaWdaWXVGWUhrYWlhNFYrc25MeEhuelpZMUFuM296UVByNEtVRjBpRVRJNkhaCjZRbEVzd24xbHBjZXFmTEV6cWlFTm9vTXhVbitYTTY2MDRDZHB2bm5INm5nOWdmY2dBclpkcS9MRWhuWHY2OVMKdmZ3V05uZWtDR202ODB5dmZqWVNKYUVpV3k2eEN4VlBlbnA1VVZpWTVidE5mRDRwSVQwYjR5MXY5ZzZjelZUbwpyUG41VS9tZHl3Z2tpRjdrRGZBb0hBPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCg==
Events:     <none>

The last hour or so of controller logs, noting that I did a rollout at 8:28.

{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"palolo.com-sm4qf","namespace":"palolo-alpha","time":"2022-04-21T17:43:01Z","message":"Successfully Reconciled"}
{"level":"debug","verbosity":4,"name":"origin-issuer/controllers/CertificateRequest","certificaterequest":{"Namespace":"palolo-alpha","Name":"palolo-com-tzrrp"},"time":"2022-04-21T19:28:49Z","message":"certificate request has not been approved"}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"palolo-com-tzrrp","namespace":"palolo-alpha","time":"2022-04-21T19:28:49Z","message":"Successfully Reconciled"}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"palolo.com-sm4qf","namespace":"palolo-alpha","time":"2022-04-21T19:28:50Z","message":"Successfully Reconciled"}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"palolo-com-tzrrp","namespace":"palolo-alpha","time":"2022-04-21T19:41:21Z","message":"Successfully Reconciled"}
{"level":"debug","verbosity":4,"name":"origin-issuer/controllers/CertificateRequest","certificaterequest":{"Namespace":"palolo-alpha","Name":"palolo-com-t5xt5"},"time":"2022-04-21T19:41:21Z","message":"certificate request has not been approved"}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"palolo-com-t5xt5","namespace":"palolo-alpha","time":"2022-04-21T19:41:21Z","message":"Successfully Reconciled"}
{"level":"debug","verbosity":4,"name":"origin-issuer/controllers/CertificateRequest","certificaterequest":{"Namespace":"cert-manager-test","Name":"selfsigned-cert-d6vvr"},"time":"2022-04-21T20:18:11Z","message":"certificate request has not been approved"}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"selfsigned-cert-d6vvr","namespace":"cert-manager-test","time":"2022-04-21T20:18:11Z","message":"Successfully Reconciled"}
{"level":"debug","verbosity":4,"name":"origin-issuer/controllers/CertificateRequest","certificaterequest":{"Namespace":"cert-manager-test","Name":"selfsigned-cert-d6vvr"},"time":"2022-04-21T20:18:11Z","message":"CertificateRequest is Ready. Ignoring."}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"selfsigned-cert-d6vvr","namespace":"cert-manager-test","time":"2022-04-21T20:18:11Z","message":"Successfully Reconciled"}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"palolo-com-t5xt5","namespace":"palolo-alpha","time":"2022-04-21T20:28:29Z","message":"Successfully Reconciled"}
{"level":"debug","verbosity":4,"name":"origin-issuer/controllers/CertificateRequest","certificaterequest":{"Namespace":"palolo-alpha","Name":"palolo-com-pvtw5"},"time":"2022-04-21T20:28:30Z","message":"certificate request has not been approved"}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"palolo-com-pvtw5","namespace":"palolo-alpha","time":"2022-04-21T20:28:30Z","message":"Successfully Reconciled"}
{"level":"debug","verbosity":4,"name":"origin-issuer/controllers/CertificateRequest","certificaterequest":{"Namespace":"palolo-alpha","Name":"palolo-com-tls-8qvb8"},"time":"2022-04-21T20:28:30Z","message":"certificate request has not been approved"}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"palolo-com-tls-8qvb8","namespace":"palolo-alpha","time":"2022-04-21T20:28:30Z","message":"Successfully Reconciled"}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.k8s.cloudflare.com","reconcilerKind":"OriginIssuer","controller":"originissuer","name":"prod-issuer","namespace":"palolo-alpha","time":"2022-04-21T20:28:30Z","message":"Successfully Reconciled"}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.k8s.cloudflare.com","reconcilerKind":"OriginIssuer","controller":"originissuer","name":"prod-issuer","namespace":"palolo-alpha","time":"2022-04-21T20:28:30Z","message":"Successfully Reconciled"}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"selfsigned-cert-d6vvr","namespace":"cert-manager-test","time":"2022-04-21T20:28:31Z","message":"Successfully Reconciled"}
{"level":"error","error":"OriginIssuer.cert-manager.k8s.cloudflare.com \"palolo-issuer\" not found","name":"origin-issuer/controllers/OriginIssuer","originissuer":{"Namespace":"palolo-alpha","Name":"palolo-issuer"},"time":"2022-04-21T20:28:32Z","message":"failed to retrieve OriginIssuer"}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.k8s.cloudflare.com","reconcilerKind":"OriginIssuer","controller":"originissuer","name":"palolo-issuer","namespace":"palolo-alpha","time":"2022-04-21T20:28:32Z","message":"Successfully Reconciled"}
{"level":"info","verbosity":1,"name":"controller","reconcilerGroup":"cert-manager.io","reconcilerKind":"CertificateRequest","controller":"certificaterequest","name":"palolo-com-pvtw5","namespace":"palolo-alpha","time":"2022-04-21T20:30:51Z","message":"Successfully Reconciled"}

Install CRDs with Helm chart

Installing CRDs as a separate step before running helm makes it more difficult to manage infrastructure using Terraform, particularly since the CRDs are currently incompatible with the Terraform Kubernetes Provider. I propose adding them to the helm chart in the same way that cert-manager has: using set installCRDs=true when running helm.

Full Strict SSL - ca.crt available for ingress

I have the OriginIssuer working and integrated with Istio.
OriginIssuer and cert-manager create a certificate with "tls.crt" and "tls.key", then an Istio Gateway resource uses those credentials to provide a certificate for the server.

The problem is, I want to use Full Strict SSL, which I believe means I need to set my Istio Gateway to Mutual TLS mode. However, I believe in order to achieve this I need the "ca.crt" available inside of the certificate secret. Which is currently not the case.

Is there a way to embed this information into the secret? It seems if you use cert-manager with your own provided CA it embeds it for you, so presumably there is the functionality.

docs: https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/#configure-a-mutual-tls-ingress-gateway

[edit] I realise I have probably gotten confused between Full Strict SSL and https://developers.cloudflare.com/access/service-auth/mtls, can someone confirm if this is the case? Also, would the same answer be possible for this other feature?

Using origin-ca-issuer w/ cert-manager shows invalid certificate

After installing cert-manager and origin-ca-issuer to the cert-manager namespace, I create a cert using annotations on the ingress object:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/issuer: origin-issuer
    cert-manager.io/issuer-group: cert-manager.k8s.cloudflare.com
    cert-manager.io/issuer-kind: OriginIssuer

Logs show:

{"level":"debug","verbosity":4,"name":"origin-issuer/controllers/CertificateRequest","certificaterequest":{"Namespace":"my-namespace","Name":"my-cert-request-name-xxxx"},"time":"2022-05-11T00:03:34Z","message":"CertificateRequest is Ready. Ignoring."}

My OriginIssuer object status shows:

  status:
    conditions:
    - lastTransitionTime: "2022-05-10T23:24:18Z"
      message: OriginIssuer verified and ready to sign certificates
      reason: Verified
      status: "True"
      type: Ready

My CertificateRequest object shows:

  conditions:
    - lastTransitionTime: '2022-05-10T23:29:34Z'
      message: Certificate request has been approved by cert-manager.io
      reason: cert-manager.io
      status: 'True'
      type: Approved
    - lastTransitionTime: '2022-05-10T23:29:34Z'
      message: Certificate issued
      reason: Issued
      status: 'True'
      type: Ready

My Certificate object shows:

status:
  conditions:
    - lastTransitionTime: '2022-05-10T23:29:34Z'
      message: Certificate is up to date and has not expired
      observedGeneration: 3
      reason: Ready
      status: 'True'
      type: Ready

However, visitng my website or issuing a curl command shows:

❯ curl -vvv https://my.domain.com/
*   Trying ip.address.goes.here:443...
* Connected to my.domain.com (ip.address.goes.here) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

	case v1.RequestTypeOriginECC:
	reqType = "origin-rsa"
	case v1.RequestTypeOriginRSA:
	reqType = "origin-ecc"