Giter Site home page Giter Site logo

cloudflare / cfssl Goto Github PK

View Code? Open in Web Editor NEW
8.5K 8.5K 1.1K 43.51 MB

CFSSL: Cloudflare's PKI and TLS toolkit

Home Page: https://cfssl.org/

License: BSD 2-Clause "Simplified" License

Go 94.66% Shell 0.04% HTML 0.03% JavaScript 1.22% Dockerfile 0.03% Assembly 3.86% Makefile 0.15%

cfssl's Introduction

CFSSL

Build Status Coverage Status GoDoc

CloudFlare's PKI/TLS toolkit

CFSSL is CloudFlare's PKI/TLS swiss army knife. It is both a command line tool and an HTTP API server for signing, verifying, and bundling TLS certificates. It requires Go 1.16+ to build.

Note that certain linux distributions have certain algorithms removed (RHEL-based distributions in particular), so the golang from the official repositories will not work. Users of these distributions should install go manually to install CFSSL.

CFSSL consists of:

  • a set of packages useful for building custom TLS PKI tools
  • the cfssl program, which is the canonical command line utility using the CFSSL packages.
  • the multirootca program, which is a certificate authority server that can use multiple signing keys.
  • the mkbundle program is used to build certificate pool bundles.
  • the cfssljson program, which takes the JSON output from the cfssl and multirootca programs and writes certificates, keys, CSRs, and bundles to disk.

Building

Building cfssl requires a working Go 1.16+ installation.

$ git clone [email protected]:cloudflare/cfssl.git
$ cd cfssl
$ make

The resulting binaries will be in the bin folder:

$ tree bin
bin
├── cfssl
├── cfssl-bundle
├── cfssl-certinfo
├── cfssl-newkey
├── cfssl-scan
├── cfssljson
├── mkbundle
└── multirootca

0 directories, 8 files

Cross Compilation

You can set the GOOS and GOARCH environment variables to have Go cross compile for alternative platforms; however, cfssl requires cgo, and cgo requires a working compiler toolchain for the target platform.

Installation

Installation requires a working Go 1.16+ installation. Alternatively, prebuilt binaries are available

$ go get github.com/cloudflare/cfssl/cmd/cfssl

will download, build, and install the CFSSL tool.

To install any of the other utility programs that are in this repo (for instance cfssljson in this case):

$ go get github.com/cloudflare/cfssl/cmd/cfssljson

This will download, build, and install the CFSSLJSON tool.

And to simply install all of the programs in this repo:

$ go get github.com/cloudflare/cfssl/cmd/...

if you are above go 1.18:

$ go install github.com/cloudflare/cfssl/cmd/...@latest

This will download, build, and install all of the utility programs (including cfssl, cfssljson, and mkbundle among others).

Using the Command Line Tool

The cfssl command line tool takes a command to specify what operation it should carry out:

   sign             signs a certificate
   bundle           build a certificate bundle
   genkey           generate a private key and a certificate request
   gencert          generate a private key and a certificate
   serve            start the API server
   version          prints out the current version
   selfsign         generates a self-signed certificate
   print-defaults   print default configurations

Use cfssl [command] -help to find out more about a command. The version command takes no arguments.

Signing

cfssl sign [-ca cert] [-ca-key key] [-hostname comma,separated,hostnames] csr [subject]

The csr is the client's certificate request. The -ca and -ca-key flags are the CA's certificate and private key, respectively. By default, they are ca.pem and ca_key.pem. The -hostname is a comma separated hostname list that overrides the DNS names and IP address in the certificate SAN extension. For example, assuming the CA's private key is in /etc/ssl/private/cfssl_key.pem and the CA's certificate is in /etc/ssl/certs/cfssl.pem, to sign the cloudflare.pem certificate for cloudflare.com:

cfssl sign -ca     /etc/ssl/certs/cfssl.pem       \
           -ca-key /etc/ssl/private/cfssl_key.pem \
           -hostname cloudflare.com               \
           ./cloudflare.pem

It is also possible to specify CSR with the -csr flag. By doing so, flag values take precedence and will overwrite the argument.

The subject is an optional file that contains subject information that should be used in place of the information from the CSR. It should be a JSON file as follows:

{
    "CN": "example.com",
    "names": [
        {
            "C":  "US",
            "L":  "San Francisco",
            "O":  "Internet Widgets, Inc.",
            "OU": "WWW",
            "ST": "California"
        }
    ]
}

N.B. As of Go 1.7, self-signed certificates will not include the AKI.

Bundling

cfssl bundle [-ca-bundle bundle] [-int-bundle bundle] \
             [-metadata metadata_file] [-flavor bundle_flavor] \
             -cert certificate_file [-key key_file]

The bundles are used for the root and intermediate certificate pools. In addition, platform metadata is specified through -metadata. The bundle files, metadata file (and auxiliary files) can be found at:

    https://github.com/cloudflare/cfssl_trust

Specify PEM-encoded client certificate and key through -cert and -key respectively. If key is specified, the bundle will be built and verified with the key. Otherwise the bundle will be built without a private key. Instead of file path, use - for reading certificate PEM from stdin. It is also acceptable that the certificate file should contain a (partial) certificate bundle.

Specify bundling flavor through -flavor. There are three flavors: optimal to generate a bundle of shortest chain and most advanced cryptographic algorithms, ubiquitous to generate a bundle of most widely acceptance across different browsers and OS platforms, and force to find an acceptable bundle which is identical to the content of the input certificate file.

Alternatively, the client certificate can be pulled directly from a domain. It is also possible to connect to the remote address through -ip.

cfssl bundle [-ca-bundle bundle] [-int-bundle bundle] \
             [-metadata metadata_file] [-flavor bundle_flavor] \
             -domain domain_name [-ip ip_address]

The bundle output form should follow the example:

{
    "bundle": "CERT_BUNDLE_IN_PEM",
    "crt": "LEAF_CERT_IN_PEM",
    "crl_support": true,
    "expires": "2015-12-31T23:59:59Z",
    "hostnames": ["example.com"],
    "issuer": "ISSUER CERT SUBJECT",
    "key": "KEY_IN_PEM",
    "key_size": 2048,
    "key_type": "2048-bit RSA",
    "ocsp": ["http://ocsp.example-ca.com"],
    "ocsp_support": true,
    "root": "ROOT_CA_CERT_IN_PEM",
    "signature": "SHA1WithRSA",
    "subject": "LEAF CERT SUBJECT",
    "status": {
        "rebundled": false,
        "expiring_SKIs": [],
        "untrusted_root_stores": [],
        "messages": [],
        "code": 0
    }
}

Generating certificate signing request and private key

cfssl genkey csr.json

To generate a private key and corresponding certificate request, specify the key request as a JSON file. This file should follow the form:

{
    "hosts": [
        "example.com",
        "www.example.com",
        "https://www.example.com",
        "[email protected]",
        "127.0.0.1"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C":  "US",
            "L":  "San Francisco",
            "O":  "Internet Widgets, Inc.",
            "OU": "WWW",
            "ST": "California"
        }
    ]
}

Generating self-signed root CA certificate and private key

cfssl genkey -initca csr.json | cfssljson -bare ca

To generate a self-signed root CA certificate, specify the key request as a JSON file in the same format as in 'genkey'. Three PEM-encoded entities will appear in the output: the private key, the csr, and the self-signed certificate.

Generating a remote-issued certificate and private key.

cfssl gencert -remote=remote_server [-hostname=comma,separated,hostnames] csr.json

This calls genkey but has a remote CFSSL server sign and issue the certificate. You may use -hostname to override certificate SANs.

Generating a local-issued certificate and private key.

cfssl gencert -ca cert -ca-key key [-hostname=comma,separated,hostnames] csr.json

This generates and issues a certificate and private key from a local CA via a JSON request. You may use -hostname to override certificate SANs.

Updating an OCSP responses file with a newly issued certificate

cfssl ocspsign -ca cert -responder key -responder-key key -cert cert \
 | cfssljson -bare -stdout >> responses

This will generate an OCSP response for the cert and add it to the responses file. You can then pass responses to ocspserve to start an OCSP server.

Starting the API Server

CFSSL comes with an HTTP-based API server; the endpoints are documented in doc/api/intro.txt. The server is started with the serve command:

cfssl serve [-address address] [-ca cert] [-ca-bundle bundle] \
            [-ca-key key] [-int-bundle bundle] [-int-dir dir] [-port port] \
            [-metadata file] [-remote remote_host] [-config config] \
            [-responder cert] [-responder-key key] [-db-config db-config]

Address and port default to "127.0.0.1:8888". The -ca and -ca-key arguments should be the PEM-encoded certificate and private key to use for signing; by default, they are ca.pem and ca_key.pem. The -ca-bundle and -int-bundle should be the certificate bundles used for the root and intermediate certificate pools, respectively. These default to ca-bundle.crt and int-bundle.crt respectively. If the -remote option is specified, all signature operations will be forwarded to the remote CFSSL.

-int-dir specifies an intermediates directory. -metadata is a file for root certificate presence. The content of the file is a json dictionary (k,v) such that each key k is an SHA-1 digest of a root certificate while value v is a list of key store filenames. -config specifies a path to a configuration file. -responder and -responder-key are the certificate and the private key for the OCSP responder, respectively.

The amount of logging can be controlled with the -loglevel option. This comes after the serve command:

cfssl serve -loglevel 2

The levels are:

  • 0 - DEBUG
  • 1 - INFO (this is the default level)
  • 2 - WARNING
  • 3 - ERROR
  • 4 - CRITICAL

The multirootca

The cfssl program can act as an online certificate authority, but it only uses a single key. If multiple signing keys are needed, the multirootca program can be used. It only provides the sign, authsign and info endpoints. The documentation contains instructions for configuring and running the CA.

The mkbundle Utility

mkbundle is used to build the root and intermediate bundles used in verifying certificates. It can be installed with

go get github.com/cloudflare/cfssl/cmd/mkbundle

It takes a collection of certificates, checks for CRL revocation (OCSP support is planned for the next release) and expired certificates, and bundles them into one file. It takes directories of certificates and certificate files (which may contain multiple certificates). For example, if the directory intermediates contains a number of intermediate certificates:

mkbundle -f int-bundle.crt intermediates

will check those certificates and combine valid certificates into a single int-bundle.crt file.

The -f flag specifies an output name; -loglevel specifies the verbosity of the logging (using the same loglevels as above), and -nw controls the number of revocation-checking workers.

The cfssljson Utility

Most of the output from cfssl is in JSON. The cfssljson utility can take this output and split it out into separate key, certificate, CSR, and bundle files as appropriate. The tool takes a single flag, -f, that specifies the input file, and an argument that specifies the base name for the files produced. If the input filename is - (which is the default), cfssljson reads from standard input. It maps keys in the JSON file to filenames in the following way:

  • if cert or certificate is specified, basename.pem will be produced.
  • if key or private_key is specified, basename-key.pem will be produced.
  • if csr or certificate_request is specified, basename.csr will be produced.
  • if bundle is specified, basename-bundle.pem will be produced.
  • if ocspResponse is specified, basename-response.der will be produced.

Instead of saving to a file, you can pass -stdout to output the encoded contents to standard output.

Static Builds

By default, the web assets are accessed from disk, based on their relative locations. If you wish to distribute a single, statically-linked, cfssl binary, you’ll want to embed these resources before building. This can by done with the go.rice tool.

pushd cli/serve && rice embed-go && popd

Then building with go build will use the embedded resources.

Additional Documentation

Additional documentation can be found in the "doc" directory:

cfssl's People

Contributors

bifurcation avatar bjt79 avatar blotus avatar cbroglie avatar claucece avatar codyli520 avatar dependabot[bot] avatar drcapulet avatar drf avatar ekristen avatar grittygrease avatar jessfraz avatar jsha avatar kayrus avatar kisom avatar lziest avatar mbrossard avatar myokoyama28 avatar nickysemenza avatar oliof avatar pde avatar rolandshoemaker avatar sevan avatar shahidhs-ibm avatar simon-xia avatar tam7t avatar terinjokes avatar thajeztah avatar wl2002 avatar zenground0 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cfssl's Issues

Update README for bundle

The README file for bundle no longer corresponds to the CLI.

  • update the example
  • tell users how to get cfssl_trust and use it for the int-bundle and ca-bundle

Enable both authenticated and unauthenticated sign endpoints when valid

The authsign endpoint is currently not very flexible. NewAuthSignHandler requires that all profiles loaded have an authentication provider. We should support both endpoints, but only if there are profiles that make sense for each.

  • the authsign endpoint should only be available for profiles that have an authentication provider, and disabled if no profiles have one.
  • the sign endpoint should only be available for profiles that do not have an authentication provider, or have an authentication provider and a remote signer.

Thoughts on versioning of cfssl?

Has any thought been given to versioning cfssl?

I'm working on a PKGBUILD for it for Arch Linux and just set it to 'git' for the version number but having version numbers would be nice for submitting it to AUR

Documentation for `cfssl genkey -initca csrjson` is incorrect

The docs say:

Generating self-signed root CA certificate and private key

cfssl genkey -initca csrjson | cfssljson -bare ca
To generate a self-signed root CA certificate, specify the key request as the JSON file in the same format as in 'genkey'. Three PEM-encoded entities will appear in the output: the private key, the csr, and the self-signed certificate.

But it only generates two things:

$ cfssl gencert -initca $c_json                     
2015/03/21 18:13:45 [ERROR] open ca-key.pem: no such file or directory
2015/03/21 18:13:45 [INFO] generating a new CA key and certificate from CSR
2015/03/21 18:13:45 [INFO] generate received request
2015/03/21 18:13:45 [INFO] received CSR
2015/03/21 18:13:45 [INFO] generating key: rsa-2048
2015/03/21 18:13:46 [INFO] encoded CSR
2015/03/21 18:13:47 [INFO] signed certificate with serial number 7336380156049125026
{"cert":"-----BEGIN CERTIFICATE-----\nMIID7jCCAtigAwIBAgIIZdAO4dKIbqIwCwYJKoZIhvcNAQELMIGEMQswCQYDVQQG\nEwJBVTEWMBQGA1UEChMNQmV2cnkgUHR5IEx0ZDEeMBwGA1UECxMVQmV2cnkgTGVh\nZGVyc2hpcCBUZWFtMQ4wDAYDVQQHEwVQZXJ0aDEaMBgGA1UECBMRV2VzdGVybiBB\ndXN0cmFsaWExETAPBgNVBAMTCGJldnJ5Lm1lMB4XDTE1MDMyMTEwMDkwMFoXDTIw\nMDMxOTEwMDkwMFowgYQxCzAJBgNVBAYTAkFVMRYwFAYDVQQKEw1CZXZyeSBQdHkg\nTHRkMR4wHAYDVQQLExVCZXZyeSBMZWFkZXJzaGlwIFRlYW0xDjAMBgNVBAcTBVBl\ncnRoMRowGAYDVQQIExFXZXN0ZXJuIEF1c3RyYWxpYTERMA8GA1UEAxMIYmV2cnku\nbWUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD5TSyYY/22DHF8DWAW\ngzvLzd8Wlym5QuJ8YQ6aamONfYxfaaIqunxJ39wFXHNyXNRYwLK8x81YjOq8GO8o\nspJ6QmUjJaSTOAccR3JuIf5a/xiC2U5YbgNm8blpPQwIOTuF/N3RUOhucQwV69WZ\nsA5nTJ/ir9re0HMruPtSVfE1xCfYikDCn4w69iLS6/DAT3dw2vWnTT24G1s3oEot\n2DawpGDzUREbKMysALc5VOiiWPE3lj90c/O87bj1iRfqp/C5OLopOFgimOpzcFiI\ntnCTnWD9/HH2Ky1cQrG/FLX+fk2y/wGZXZkBgf9YsJfck1G8zizvBJT2lFEew0TA\nNH0DAgMBAAGjZjBkMA4GA1UdDwEB/wQEAwIABjASBgNVHRMBAf8ECDAGAQH/AgEC\nMB0GA1UdDgQWBBQU2/pm/e0EJYClmYbEzWTVnZQHdTAfBgNVHSMEGDAWgBQU2/pm\n/e0EJYClmYbEzWTVnZQHdTALBgkqhkiG9w0BAQsDggEBAF1t4ZRJqnAIKHF1ZguP\ns2dTOoJIm1P0CaX1HKu2rHGrCqFpJLGcpW3lvzVuvvL0WCs+sPUWvJ96p4XEiLWX\nCSw+ZQuDGvkJRQf+43WkEr53E7bADkon/cji/iVjI761AcHLX4WryDhLxff/Vxa0\nylZh9Dx5PDvMbhCUgQfSnSdZZWQuFRiNR6TItsPQ/wV3/mtyvlczJOnEovyAHGTq\ntTBD69ZqS1PQMh8pawi4W9jk7MKznNlzN3o5HHqabK3HlKvMVlHF9fpq2YcFDEmh\nh+r5B+agWxg+asK8ILtG7LAIgKexMSrXrjSPePgJWs3pyxJ32VCOntRcv58r3PNb\nBgM=\n-----END CERTIFICATE-----\n","key":"-----BEGIN RSA PRIVATE KEY-----\nMIIEogIBAAKCAQEA+U0smGP9tgxxfA1gFoM7y83fFpcpuULifGEOmmpjjX2MX2mi\nKrp8Sd/cBVxzclzUWMCyvMfNWIzqvBjvKLKSekJlIyWkkzgHHEdybiH+Wv8YgtlO\nWG4DZvG5aT0MCDk7hfzd0VDobnEMFevVmbAOZ0yf4q/a3tBzK7j7UlXxNcQn2IpA\nwp+MOvYi0uvwwE93cNr1p009uBtbN6BKLdg2sKRg81ERGyjMrAC3OVTooljxN5Y/\ndHPzvO249YkX6qfwuTi6KThYIpjqc3BYiLZwk51g/fxx9istXEKxvxS1/n5Nsv8B\nmV2ZAYH/WLCX3JNRvM4s7wSU9pRRHsNEwDR9AwIDAQABAoIBACywbOIUapKLwHwg\nWa0vcTSjfu4pwsz29Gqfa2K614Wxj8w6v1sxer4zZtl/LSK/CUGvqVq15lWNTTbS\nsWx2NlO8Oy0Fvm61iHDFTfn4FgRx3g72rVikv+9gPYBj9Rg0SjtGjOzMuB20Hhp/\n4BZgvPQ/hBm6tF1kuICJ9GNaDJc6a+eP4Vo58ugZ3m8WEIQ6ay0QMiIyOvSx/r44\ntegD2NAQr5DWywS03ZL9MBujgpMapfbacRbbnbjjTS/9IvjygMjX68EAJ+20uuL4\nQqQ9vGE9WUoXD9ekzdVEjuKjDXd5/lCW8Kv3e0yI3QQnYjCG/DGvoqSaPBFjKppw\nmAbSq8ECgYEA/HQCaahcUsiYRKwygavgRHWMNE2JuUvYV5TadkkW4ZRQXx2dgp6N\n23W3Z9Cns72F9wNmBVNNskYwuPX0mI84g8vhTf67Y4vdJfiDViSXqFBH9IvXVdav\nb7dGvu/iTwgQp6Bzy3iiD9p+OucW8QCSZkH6PZ6iDVknKgTeobHHlZkCgYEA/M3U\nQ1BoEeq5ErCxmQr0694Ix7+md3V6/E8x0iJtz8CDFWnUEmBd4L3EDnQwxpMgAcEf\nlH1wxKJikOFImbjuCWZ72A38ze9HCtPwSVTbvWPO3/M6Ev+93azzfYEkoMjEKc7K\nSl+pVaNk1YF0jl5Jr5VqokGMRD7e0IM0VooNUPsCgYAEuftNlRxdZGoNZxfu+5PQ\nVE8Sr5zzfisHwL6yVj36bTdwAHLxfhxzzmlnpS1unQ7ECClB0kRzIQNKgzhYHt5V\nAV0vg6RogbbbPiLfWwIH4bDnMDMQ5VsVgV3utzkKd8EwEj34wkJuf427dpYkXvle\ntr+DpdOs4k1saPjuGBD/iQKBgFytsLWE0sJOxM6fTFyI8cVOvvVLw2FkBlRdTCx3\nRr61GtlM1Nxvy7rKlwedfQwvf7pk7Ijpe9/6kBwBGzaP32Q+2AQbDKUKpYbIr/yS\nSYSjBIKBjrbMXvTXpORL5fuz3oZdMzgU3eVxY1QKg4p18pmWM2OMmDmkutbCYvue\n3MblAoGAShBFBb4Bq4VK9OF06H3tjzk9+WIIwQP0jD6f4iVLkOM93SUMMMzkSsyq\nzB5oik4tG8rbg/Gk6cjjO1W0Nyvj/azaS0/RXZo3nAjUQZ8hxvIbVkRbc1krgcl5\nzCdk+NUH7HmvxoF7CkDh8+HlAoSd+di0D1Pv6lxMt1GfQfiWurs=\n-----END RSA PRIVATE KEY-----\n"}

What is `ca` and `key` in the documentation?

There is:

Generating a local-issued certificate and private key.

cfssl gencert -ca cert -ca-key key hostname csrjson
This is generates and issues a certificate and private key from a local CA via a JSON request.

However, what is cert and key, are they that generated from:

$ cfssl genkey $c_json | cfssljson -bare ca
2015/03/21 18:16:10 [INFO] generate received request
2015/03/21 18:16:10 [INFO] received CSR
2015/03/21 18:16:10 [INFO] generating key: rsa-2048
2015/03/21 18:16:10 [INFO] encoded CSR
$ ls
ca-key.pem ca.csr

Or that generated from:

$ cfssl gencert -initca $c_json | cfssljson -bare ca
2015/03/21 18:16:34 [ERROR] open ca-key.pem: no such file or directory
2015/03/21 18:16:34 [INFO] generating a new CA key and certificate from CSR
2015/03/21 18:16:34 [INFO] generate received request
2015/03/21 18:16:34 [INFO] received CSR
2015/03/21 18:16:34 [INFO] generating key: rsa-2048
2015/03/21 18:16:35 [INFO] encoded CSR
2015/03/21 18:16:35 [INFO] signed certificate with serial number 8039957226077408897
$ ls
ca-key.pem ca.pem

cfssl serve logs to STDERR on startup

Some messages are informational, and probably belong on STDOUT. Errors can go to STDERR.

Or better yet, accept an argument for the filepath to log to?

undefined: crypto.Signer

Installing cfssl based on the package gives this error.

himalaya:~ suresh$ go get -u github.com/cloudflare/cfssl/cmd/cfssl

github.com/cloudflare/cfssl/helpers

go/src/github.com/cloudflare/cfssl/helpers/helpers.go:187: undefined: crypto.Signer
go/src/github.com/cloudflare/cfssl/helpers/helpers.go:198: undefined: crypto.Signer

golang.org/x/crypto/ocsp

go/src/golang.org/x/crypto/ocsp/ocsp.go:482: undefined: crypto.Signer

Support CSRs with "challengePassword" and other fields

Currently, CFSSL fails on certain input CSRs. Specifically, requests with the "challengePassword" field cause CFSSL to return:
{"code":1003,"message":"asn1: structure error: sequence tag mismatch"}

Test data can be created with:
openssl req -nodes -newkey rsa:2048
with strings set for either of the two following fields:

  • A challenge password []:
  • An optional company name []:

Add support for remote `info` endpoint

Currently, if CFSSL is set up to use a remote signer, the info endpoint will not return the right certificate. It will return information for the local certificate instead of the remote certificate.

The info command should return the right certificate for a given label. This can be done by a call to the remote CFSSL using the appropriate authentication. This call should incorporate the "label" parameter.

The remote.Signer's Certificate() function (https://github.com/cloudflare/cfssl/blob/master/signer/remote/remote.go#L80) should also be updated to use the new remote info endpoint in a similar way.

Certificate bundles and metadata

I see that the bundle command requires several files in /etc/cfssl which don't seem to be provided with the distribution. How/where should those be obtained?

Support OCSP in serve

The API should have the ability to serve OCSP responses in cfssl serve. This should include a signer/universal type shim to either sign locally or remotely.

Install / Build error

I'm trying to install cfssl on Fedora20. I installed go and set up $GOPATH. When I tried to install I get errors. Here is the complete log:

$ sudo yum -y install go

(unnecessary lines removed)

Installed:
golang.x86_64 0:1.2.2-22.fc20
Dependency Installed:
golang-pkg-bin-linux-amd64.x86_64 0:1.2.2-22.fc20
golang-pkg-linux-amd64.noarch 0:1.2.2-22.fc20
golang-src.noarch 0:1.2.2-22.fc20
Complete!

$ mkdir $HOME/go
$ export GOPATH=$HOME/go
$ export PATH=$PATH:$GOPATH/bin
$ go get github.com/cloudflare/cfssl
github.com/cloudflare/cfssl/csr <-- # removed from start of this line for formatting
go/src/github.com/cloudflare/cfssl/csr/csr.go:189: undefined: x509.CertificateRequest
go/src/github.com/cloudflare/cfssl/csr/csr.go:194: undefined: x509.CreateCertificateRequest
$

I'm sure it's something stupid, but as I know zero about go I don't know what to do next.

Unable to generate intermediate certificate with cfssl

I'm using the following configuration for cfssl:

{
        "signing": {
                "default": {
                        "expiry": "168h"
                },
                "profiles": {
                        "www": {
                                "usages": [
                                        "signing",
                                        "key encipherment",
                                        "server auth"
                                ],
                "expiry": "168h"
                        },
                        "client": {
                                "usages": [
                                        "signing",
                                        "key encipherment",
                                        "client auth"
                ],
                "expiry": "168h"
                        },
                        "intermediate": {
                                "usages": [
                                        "signing",
                                        "key encipherment",
                                        "cert sign",
                                        "crl sign"
                                ],
                                "expiry": "720h",
                                "CA": true
                        }
                }
        }
}

And the following CSR:

{
    "CN": "Test CA - G3",
    "hosts": [
        ""
    ],
    "key": {
        "algo": "ecdsa",
        "size": 521
    },
    "names": [
        {
            "OU": "Certificate Authority Division",
            "O": "Test CA",
            "L": "Los Angeles",
            "C": "US"
        }
    ]
}

If I invoked cfssl as cfssl -loglevel=0 gencert -f=config.json -profile="intermediate" "" csr.json | cfssljson -bare ca, I expect the resulting certificate to:

  • include the specified X.509 basic constraints
  • have its CA bit set to true
  • perhaps the CA depth be set to the root's - 1, too.

But cfssl generates instead a non-CA certificate, with an innecessary SAN section:

luna@luna-VirtualBox:~/Escritorio/cfssl$ openssl x509 -in ca.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 784610169511137649 (0xae37ecac8ded171)
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: ***
        Validity
            Not Before: Oct  7 16:30:26 2014 GMT
            Not After : Nov  6 16:35:26 2014 GMT
        Subject: ***
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (521 bit)
                pub: 
                    04:01:11:91:3c:10:71:12:75:6a:45:47:5d:1d:bf:
                    6f:1d:13:6e:96:ca:fa:14:3e:4e:62:a8:78:fb:46:
                    94:ca:b9:c6:5e:76:fc:38:1b:8d:1c:1d:fa:03:15:
                    b5:e7:cc:2e:db:a2:80:b5:93:d8:d8:ac:56:eb:9b:
                    49:e0:ca:cc:e8:49:be:01:35:13:de:da:f5:c2:60:
                    3c:09:9f:27:f4:4c:82:dc:8f:b2:18:0e:b6:28:a1:
                    33:64:f1:fd:52:79:75:f7:ae:ed:73:93:b7:5d:e4:
                    9b:e0:84:90:33:95:ae:f2:ed:24:eb:68:b7:e7:a1:
                    48:9a:ba:82:17:50:59:20:63:dd:28:a0:59
                ASN1 OID: secp521r1
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier: 
                D4:57:23:3F:DB:B1:4A:99:10:25:C6:86:54:FD:E6:03:77:EE:54:7A
            X509v3 Authority Key Identifier: 
                keyid:FE:B2:06:AC:78:E0:49:4C:B1:1B:ED:4E:D7:3F:EA:20:19:47:C0:3D

            X509v3 Subject Alternative Name: 
                DNS:
    Signature Algorithm: ecdsa-with-SHA256
         30:46:02:21:00:e5:88:52:a1:be:30:d9:de:3f:5b:2a:89:b6:
         df:e6:be:9c:bc:17:fe:0e:a3:65:be:0e:0b:fc:5e:dc:c6:48:
         dc:02:21:00:ae:96:f0:5d:45:9a:cc:fb:1b:e8:45:05:e4:50:
         15:48:d8:f4:37:70:65:68:1b:e3:68:f8:e6:58:93:68:e3:98

Optionally overwrite CSR fields in sign

Currently, if you call the sign API but do not include the subject, distinguished names or CN, then these fields will be blank in the certificate. Instead, sign should take these parameters from the CSR directly if they are missing in the API call.

Add support for multiple hostnames in the sign CLI and API

Right now, the CLI for sign takes the hostname as a parameter or as a flag (-hostname). In the csr.CertificateRequest, cfssl accepts multiple hostnames, it should also do so if provided as the hostname.

The hostname parameter should be augmented to accept a comma-separated list of hostnames/IPs. This will allow the creation of multiple-SAN certs from the command line.

User authentication system

We would like to implement a user authentication system with an LDAP provider as the authentication backend. The only issue is that once you pass your credentials, you should be able to authenticate further requests based on some sort of session key.

It would be nice to have a configurable session timeout, and also support service tokens so other services could use this as well.

Would this be an addition that you guys would like to support? I can code this, but trying to determine if I should build it separately.

Thanks,
Steve

PKCS #12 file generation for client certificates

This utility has been great making the keys and signing certs but it doesn't seem oriented towards client certificates, but it's 80% of the way there. It would be useful to be able to generate client keys and sign them with a CA key and then be able to easily package them in a .p12/pfx file that can be installed in browser or used in a client library.

ca_key.pem file name

This caught me off-guard, although I'm not sure whether it is a bug or not.

The cfssljson tool created ca-key.pem, but cfssl serve looks for ca_key.pem by default.


When I run:

$ cfssl genkey -initca /etc/cfssl/ca.json | cfssljson ca

two files are created:

$ ls
ca-key.pem  ca.pem

When I run:

$ cfssl serve
...
2014/07/11 14:01:12 [ERROR] setting up signer failed: open ca_key.pem: no such file or directory
...

Fix coveralls for pull requests from forks

Coveralls currently fails for every pull request from a remote fork. The secure token in TravisCI to authenticate to coveralls doesn't seem to be decrypted properly in this case.

Revocation

First of all: thanks for the release!

I don't see anything in the CA functionality about revoking signed certificates, is this because revocation isn't really useful or is it for another reason?

Add profile information into info endpoint

The info endpoint currently only presents information about the key pointed to by a given label. It should also print out information about the profile.

This includes:

  • Duration
  • Mandatory extensions (client auth, server auth, etc.)

Support PKCS#12/PFX format in bundle

PKCS#12/PFX Format:

http://en.wikipedia.org/wiki/PKCS_12
The PKCS#12 or PFX format is a binary format for storing the server certificate, any intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys.

The certificate chain provided in the PKCS#12 bundle should be used and if the key is provided in the PKCS#12 bundle, then the "key" parameter is optional.

Make a release

at the moment there's no tags, or releases. it would be helpful to folks who actually want to use this if there was a known release, as opposed to track trunk.

cfssljson tool cannot parse json generated by cfssl

gareth@Queeg test]$ bin/cfssl bundle /tmp/cloudflare.crt >cloudflare.json 2>/dev/null
[gareth@Queeg test]$ bin/cfssljson cf <cloudflare.json 
Failed to parse input: json: cannot unmarshal number into Go value of type string

cfssljson.go line 40 uses a map[string]string to hold the json output, but not all of the values in the generated json are strings (eg. key_size), hence the error.

Using a map[string]interface{} and then doing an type assertion to a string works, but didn't know if there's a reason why it is the way it is right now

Support multiple remotes

CFSSL currently can't handle when a remote is not available. Adding multiple remotes allows for higher availability.

on the command line: comma separated remotes
in the config: an array of remotes

They should be treated in order or priority: if the connection fails to the first remote, it should fall back to the next one.

Add info command

The info API endpoint returns information about the certificate used for a CA. With the latest changes from issue #98, info can return information about remote signers. There should be a command line option to return information about remote signers.

Options to take: remote, label, profile, config

"hosts" parameter in JSON request is ignored when signing a new certificate

I'm using the following boilerplate JSON request, csrjson:

{
    "hosts": [
        "example.com",
        "www.example.com"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "US",
            "L": "San Francisco",
            "O": "Internet Widgets, Inc.",
            "OU": "WWW",
            "ST": "California"
        }
    ]
}

After creating a suitable CA certificate, when attempting to generate and sign a new client certificate:

cfssl gencert example.com csrjson | cfssljson -bare

I would expect it to include example.com and www.example com as Subject Alternative Names. But instead, it only includes the specified hostname, example.com:

luna@luna-VirtualBox:/tmp/tmp$ openssl x509 -in cert.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 7662139354499468246 (0x6a556325ac7b4bd6)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Internet Widgets, Inc., OU=WWW, L=San Francisco, ST=California
        Validity
            Not Before: Oct  7 02:59:22 2014 GMT
            Not After : Oct  7 03:04:22 2015 GMT
        Subject: C=US, O=Example Organisation, L=San Francisco, ST=California, CN=example.com
        Subject Public Key Info:
... snip ...
            X509v3 Subject Alternative Name: 
                DNS:example.com
    Signature Algorithm: sha256WithRSAEncryption
... snip ...

I believe this is not the intended behavior. Would anyone please confirm this?

Add support for creating dummy certificates, servers, etc. when testing

Currently, all testing seems to be done with static certificate chains which were created for that test from the command line. It would be more streamlined to be able to create your own instances in the test code itself. Issue #96 references a similar problem and suggests the ability to create a test server. Ideally, one should be able to create a dummy version of anything they might need in a test. If you need something besides certificate chains and servers, please say so in a comment.

Flag.Usage is nil, causes panic

For some reason I don't understand, flag.Usage is set to nil in main.

Then in cli.Start:

    flag.Parse()
    if flag.Usage == nil {
        flag.Usage = func() {
            fmt.Fprintf(os.Stderr, usage)
            for name := range cmds {
                fmt.Fprintf(os.Stderr, "%s\n", name)
            }
        }
    }

flag.Parse panics if it has to call Usage (like when you have a wrong flag). The quick fix is to move it under the if, but I'm afraid there are other calls of flag functions that might fail around.

Unable to clear C, ST, O, OU, L in CSR

The recently added method replaceSliceIfEmpty from aeaf899bba868e70ba78c478be99b7b4cb266915 interferes with clearing unwanted Name fields.

The logic today chooses to copy the CSR-supplied Name fields if the signer.Subject object includes strings of length 0.

We need to be able to clear these fields, as we cannot trust the user's input, but passing strings of length 0 no longer does the trick. Of course, we can't send nil pointers either.

We need some better way to indicate to CFSSL to discard the CSR names.

CRL url generation issue?

generating certs with CRL urls seems to have a bit of an issue, it may be more with go than cfssl. Using this over openssl there seems to be a bit of an issue. openssl parses the certs and shows the correct CRL url but both firefox and internet explorer seem to have an issue reading the url from the certs generated. In IE it shows as the hex/ascii value of:
30 2c 30 2a a0 28 80 26
86 24
before the http:// of the url) FF just doesn't show any url.
the bundler decodes it fine and validates without issue.

Why is `hostname` needed if we support multiple hosts?

My JSON looks like:

{
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "hosts": [
    "blah.com",
    "bleh.com",
    "blog.com"
  ],
  "CN": "blah.com",
  "names": [
    {
      "C": "asd",
      "L": "asd",
      "ST": "asd",
      "O": "asd",
      "OU": "asd"
    }
  ]
}

Why when I want the certificate to support the 3 hosts mentioned in my javascript file, I need to:

  1. Specify hostname in: cfssl gencert -ca $c_cert -ca-key $c_key $c_hostname $c_json | cfssljson -bare ca?
  2. Specify CN in my json file?

Update installation instructions for RHEL-like linux distributions

Because of patents on elliptic curve crypto, Red Hat patches the golang distributions in its repos to remove it. Therefore, users of linux distributions based on Red Hat (Fedora, SUSE, etc) will have to install golang manually for CFSSL to build. This should be mentioned in the README, or people will not know why CFSSL fails to build.

Allow signing policy when generating a new CA with -initca

When generating an intermediate CA, one could add an OCSP or CRL URL by using signing policies:

{
 "signing": {
   "default": {
     "usages": [
       "signing",
       "key encipherment",
       "cert sign",
       "crl sign"
      ],
      "expiry": "4320h",
      "is_ca": true,
      "crl_url": "https://test-ca.sky/ca/sky-ocean-g2.crl",
      "issuer_urls": ["https://test-ca.sky"]
    }
  }
}

It would be nice if the same were allowed when generating a root CA, because initca.go currently forces a default signing policy in this case.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.