github.com/silveraid/fabric-ca@v1.1.0-preview.0.20180127000700-71974f53ab08/docs/source/users-guide.rst (about)

     1  Fabric CA User's Guide
     2  ======================
     3  
     4  The Hyperledger Fabric CA is a Certificate Authority (CA)
     5  for Hyperledger Fabric.
     6  
     7  It provides features such as:
     8  
     9    * registration of identities, or connects to LDAP as the user
    10      registry
    11    * issuance of Enrollment Certificates (ECerts)
    12    * certificate renewal and revocation
    13  
    14  Hyperledger Fabric CA consists of both a server and a client component as
    15  described later in this document.
    16  
    17  For developers interested in contributing to Hyperledger Fabric CA, see the
    18  `Fabric CA repository <https://github.com/hyperledger/fabric-ca>`__ for more
    19  information.
    20  
    21  
    22  .. _Back to Top:
    23  
    24  Table of Contents
    25  -----------------
    26  
    27  1. `Overview`_
    28  
    29  2. `Getting Started`_
    30  
    31     1. `Prerequisites`_
    32     2. `Install`_
    33     3. `Explore the Fabric CA CLI`_
    34  
    35  3. `Configuration Settings`_
    36  
    37     1. `A word on file paths`_
    38  
    39  4. `Fabric CA Server`_
    40  
    41     1. `Initializing the server`_
    42     2. `Starting the server`_
    43     3. `Configuring the database`_
    44     4. `Configuring LDAP`_
    45     5. `Setting up a cluster`_
    46     6. `Setting up multiple CAs`_
    47     7. `Enrolling an intermediate CA`_
    48  
    49  5. `Fabric CA Client`_
    50  
    51     1. `Enrolling the bootstrap identity`_
    52     2. `Registering a new identity`_
    53     3. `Enrolling a peer identity`_
    54     4. `Reenrolling an identity`_
    55     5. `Revoking a certificate or identity`_
    56     6. `Generating a CRL (Certificate Revocation List)`_
    57     7. `Attribute-Based Access Control`_
    58     8. `Enabling TLS`_
    59     9. `Contact specific CA instance`_
    60  
    61  6. `HSM`_
    62  
    63     1. `Configuring Fabric CA server to use softhsm2`_
    64  
    65  7. `File Formats`_
    66  
    67     1. `Fabric CA server's configuration file format`_
    68     2. `Fabric CA client's configuration file format`_
    69  
    70  8. `Troubleshooting`_
    71  
    72  Overview
    73  --------
    74  
    75  The diagram below illustrates how the Hyperledger Fabric CA server fits into the
    76  overall Hyperledger Fabric architecture.
    77  
    78  .. image:: ./images/fabric-ca.png
    79  
    80  There are two ways of interacting with a Hyperledger Fabric CA server:
    81  via the Hyperledger Fabric CA client or through one of the Fabric SDKs.
    82  All communication to the Hyperledger Fabric CA server is via REST APIs.
    83  See `fabric-ca/swagger/swagger-fabric-ca.json` for the swagger documentation
    84  for these REST APIs.
    85  You may view this documentation via the http://editor2.swagger.io online editor.
    86  
    87  The Hyperledger Fabric CA client or SDK may connect to a server in a cluster
    88  of Hyperledger Fabric CA servers.   This is illustrated in the top right section
    89  of the diagram. The client routes to an HA Proxy endpoint which load balances
    90  traffic to one of the fabric-ca-server cluster members.
    91  
    92  All Hyperledger Fabric CA servers in a cluster share the same database for
    93  keeping track of identities and certificates.  If LDAP is configured, the identity
    94  information is kept in LDAP rather than the database.
    95  
    96  A server may contain multiple CAs.  Each CA is either a root CA or an
    97  intermediate CA.  Each intermediate CA has a parent CA which is either a
    98  root CA or another intermediate CA.
    99  
   100  Getting Started
   101  ---------------
   102  
   103  Prerequisites
   104  ~~~~~~~~~~~~~~~
   105  
   106  -  Go 1.9+ installation
   107  -  ``GOPATH`` environment variable is set correctly
   108  - libtool and libtdhl-dev packages are installed
   109  
   110  The following installs the libtool dependencies on Ubuntu:
   111  
   112  .. code:: bash
   113  
   114     sudo apt install libtool libltdl-dev
   115  
   116  The following installs the libtool dependencies on MacOSX:
   117  
   118  .. code:: bash
   119  
   120     brew install libtool
   121  
   122  .. note:: libtldl-dev is not necessary on MacOSX if you instal
   123            libtool via Homebrew
   124  
   125  For more information on libtool, see https://www.gnu.org/software/libtool.
   126  
   127  For more information on libltdl-dev, see https://www.gnu.org/software/libtool/manual/html_node/Using-libltdl.html.
   128  
   129  Install
   130  ~~~~~~~
   131  
   132  The following installs both the `fabric-ca-server` and `fabric-ca-client` binaries
   133  in $GOPATH/bin.
   134  
   135  .. code:: bash
   136  
   137      go get -u github.com/hyperledger/fabric-ca/cmd/...
   138  
   139  Note: If you have already cloned the fabric-ca repository, make sure you are on the
   140  master branch before running the 'go get' command above. Otherwise, you might see the
   141  following error:
   142  
   143  ::
   144  
   145      <gopath>/src/github.com/hyperledger/fabric-ca; git pull --ff-only
   146      There is no tracking information for the current branch.
   147      Please specify which branch you want to merge with.
   148      See git-pull(1) for details.
   149  
   150          git pull <remote> <branch>
   151  
   152      If you wish to set tracking information for this branch you can do so with:
   153  
   154          git branch --set-upstream-to=<remote>/<branch> tlsdoc
   155  
   156      package github.com/hyperledger/fabric-ca/cmd/fabric-ca-client: exit status 1
   157  
   158  Start Server Natively
   159  ~~~~~~~~~~~~~~~~~~~~~
   160  
   161  The following starts the `fabric-ca-server` with default settings.
   162  
   163  .. code:: bash
   164  
   165      fabric-ca-server start -b admin:adminpw
   166  
   167  The `-b` option provides the enrollment ID and secret for a bootstrap
   168  administrator; this is required if LDAP is not enabled with the "ldap.enabled"
   169  setting.
   170  
   171  A default configuration file named `fabric-ca-server-config.yaml`
   172  is created in the local directory which can be customized.
   173  
   174  Start Server via Docker
   175  ~~~~~~~~~~~~~~~~~~~~~~~
   176  
   177  Docker Hub
   178  ^^^^^^^^^^^^
   179  
   180  Go to: https://hub.docker.com/r/hyperledger/fabric-ca/tags/
   181  
   182  Find the tag that matches the architecture and version of fabric-ca
   183  that you want to pull.
   184  
   185  Navigate to `$GOPATH/src/github.com/hyperledger/fabric-ca/docker/server`
   186  and open up docker-compose.yml in an editor.
   187  
   188  Change the `image` line to reflect the tag you found previously. The file
   189  may look like this for an x86 architecture for version beta.
   190  
   191  .. code:: yaml
   192  
   193      fabric-ca-server:
   194        image: hyperledger/fabric-ca:x86_64-1.0.0-beta
   195        container_name: fabric-ca-server
   196        ports:
   197          - "7054:7054"
   198        environment:
   199          - FABRIC_CA_HOME=/etc/hyperledger/fabric-ca-server
   200        volumes:
   201          - "./fabric-ca-server:/etc/hyperledger/fabric-ca-server"
   202        command: sh -c 'fabric-ca-server start -b admin:adminpw'
   203  
   204  Open up a terminal in the same directory as the docker-compose.yml file
   205  and execute the following:
   206  
   207  .. code:: bash
   208  
   209      # docker-compose up -d
   210  
   211  This will pull down the specified fabric-ca image in the compose file
   212  if it does not already exist, and start an instance of the fabric-ca
   213  server.
   214  
   215  Building Your Own Docker image
   216  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   217  
   218  You can build and start the server via docker-compose as shown below.
   219  
   220  .. code:: bash
   221  
   222      cd $GOPATH/src/github.com/hyperledger/fabric-ca
   223      make docker
   224      cd docker/server
   225      docker-compose up -d
   226  
   227  The hyperledger/fabric-ca docker image contains both the fabric-ca-server and
   228  the fabric-ca-client.
   229  
   230  .. code:: bash
   231  
   232      # cd $GOPATH/src/github.com/hyperledger/fabric-ca
   233      # FABRIC_CA_DYNAMIC_LINK=true make docker
   234      # cd docker/server
   235      # docker-compose up -d
   236  
   237  Explore the Fabric CA CLI
   238  ~~~~~~~~~~~~~~~~~~~~~~~~~~~
   239  
   240  This section simply provides the usage messages for the Fabric CA server and client
   241  for convenience.  Additional usage information is provided in following sections.
   242  
   243  The following links shows the :doc:`Server Command Line <servercli>` and
   244  :doc:`Client Command Line <clientcli>`.
   245  
   246  .. note:: Note that command line options that are string slices (lists) can be
   247            specified either by specifying the option with comma-separated list
   248            elements or by specifying the option multiple times, each with a
   249            string value that make up the list. For example, to specify
   250            ``host1`` and ``host2`` for the ``csr.hosts`` option, you can either
   251            pass ``--csr.hosts 'host1,host2'`` or
   252            ``--csr.hosts host1 --csr.hosts host2``. When using the former format,
   253            please make sure there are no space before or after any commas.
   254  
   255  `Back to Top`_
   256  
   257  Configuration Settings
   258  ~~~~~~~~~~~~~~~~~~~~~~
   259  
   260  The Fabric CA provides 3 ways to configure settings on the Fabric CA server
   261  and client. The precedence order is:
   262  
   263    1. CLI flags
   264    2. Environment variables
   265    3. Configuration file
   266  
   267  In the remainder of this document, we refer to making changes to
   268  configuration files. However, configuration file changes can be
   269  overridden through environment variables or CLI flags.
   270  
   271  For example, if we have the following in the client configuration file:
   272  
   273  .. code:: yaml
   274  
   275      tls:
   276        # Enable TLS (default: false)
   277        enabled: false
   278  
   279        # TLS for the client's listenting port (default: false)
   280        certfiles:
   281        client:
   282          certfile: cert.pem
   283          keyfile:
   284  
   285  The following environment variable may be used to override the ``cert.pem``
   286  setting in the configuration file:
   287  
   288  .. code:: bash
   289  
   290    export FABRIC_CA_CLIENT_TLS_CLIENT_CERTFILE=cert2.pem
   291  
   292  If we wanted to override both the environment variable and configuration
   293  file, we can use a command line flag.
   294  
   295  .. code:: bash
   296  
   297    fabric-ca-client enroll --tls.client.certfile cert3.pem
   298  
   299  The same approach applies to fabric-ca-server, except instead of using
   300  ``FABIRC_CA_CLIENT`` as the prefix to environment variables,
   301  ``FABRIC_CA_SERVER`` is used.
   302  
   303  .. _server:
   304  
   305  A word on file paths
   306  ^^^^^^^^^^^^^^^^^^^^^
   307  All the properties in the Fabric CA server and client configuration file
   308  that specify file names support both relative and absolute paths.
   309  Relative paths are relative to the config directory, where the
   310  configuration file is located. For example, if the config directory is
   311  ``~/config`` and the tls section is as shown below, the Fabric CA server
   312  or client will look for the ``root.pem`` file in the ``~/config``
   313  directory, ``cert.pem`` file in the ``~/config/certs`` directory and the
   314  ``key.pem`` file in the ``/abs/path`` directory
   315  
   316  .. code:: yaml
   317  
   318      tls:
   319        enabled: true
   320        certfiles:
   321          - root.pem
   322        client:
   323          certfile: certs/cert.pem
   324          keyfile: /abs/path/key.pem
   325  
   326  `Back to Top`_
   327  
   328  Fabric CA Server
   329  ----------------
   330  
   331  This section describes the Fabric CA server.
   332  
   333  You may initialize the Fabric CA server before starting it. This provides an
   334  opportunity for you to generate a default configuration file that can be
   335  reviewed and customized before starting the server.
   336  
   337  The Fabric CA server's home directory is determined as follows:
   338    - if the --home command line option is set, use its value
   339    - otherwise, if the ``FABRIC_CA_SERVER_HOME`` environment variable is set, use
   340      its value
   341    - otherwise, if ``FABRIC_CA_HOME`` environment variable is set, use
   342      its value
   343    - otherwise, if the ``CA_CFG_PATH`` environment variable is set, use
   344      its value
   345    - otherwise, use current working directory
   346  
   347  For the remainder of this server section, we assume that you have set
   348  the ``FABRIC_CA_HOME`` environment variable to
   349  ``$HOME/fabric-ca/server``.
   350  
   351  The instructions below assume that the server configuration file exists
   352  in the server's home directory.
   353  
   354  .. _initialize:
   355  
   356  Initializing the server
   357  ~~~~~~~~~~~~~~~~~~~~~~~
   358  
   359  Initialize the Fabric CA server as follows:
   360  
   361  .. code:: bash
   362  
   363      fabric-ca-server init -b admin:adminpw
   364  
   365  The ``-b`` (bootstrap identity) option is required for initialization when
   366  LDAP is disabled. At least one bootstrap identity is required to start the
   367  Fabric CA server; this identity is the server administrator.
   368  
   369  The server configuration file contains a Certificate Signing Request (CSR)
   370  section that can be configured. The following is a sample CSR.
   371  
   372  .. _csr-fields:
   373  
   374  .. code:: yaml
   375  
   376     cn: fabric-ca-server
   377     names:
   378        - C: US
   379          ST: "North Carolina"
   380          L:
   381          O: Hyperledger
   382          OU: Fabric
   383     hosts:
   384       - host1.example.com
   385       - localhost
   386     ca:
   387        expiry: 131400h
   388        pathlength: 1
   389  
   390  All of the fields above pertain to the X.509 signing key and certificate which
   391  is generated by the ``fabric-ca-server init``.  This corresponds to the
   392  ``ca.certfile`` and ``ca.keyfile`` files in the server's configuration file.
   393  The fields are as follows:
   394  
   395    -  **cn** is the Common Name
   396    -  **O** is the organization name
   397    -  **OU** is the organizational unit
   398    -  **L** is the location or city
   399    -  **ST** is the state
   400    -  **C** is the country
   401  
   402  If custom values for the CSR are required, you may customize the configuration
   403  file, delete the files specified by the ``ca.certfile`` and ``ca-keyfile``
   404  configuration items, and then run the ``fabric-ca-server init -b admin:adminpw``
   405  command again.
   406  
   407  The ``fabric-ca-server init`` command generates a self-signed CA certificate
   408  unless the ``-u <parent-fabric-ca-server-URL>`` option is specified.
   409  If the ``-u`` is specified, the server's CA certificate is signed by the
   410  parent Fabric CA server.
   411  In order to authenticate to the parent Fabric CA server, the URL must
   412  be of the form ``<scheme>://<enrollmentID>:<secret>@<host>:<port>``, where
   413  <enrollmentID> and <secret> correspond to an identity with an 'hf.IntermediateCA'
   414  attribute whose value equals 'true'.
   415  The ``fabric-ca-server init`` command also generates a default configuration
   416  file named **fabric-ca-server-config.yaml** in the server's home directory.
   417  
   418  If you want the Fabric CA server to use a CA signing certificate and key file which you provide,
   419  you must place your files in the location referenced by ``ca.certfile`` and ``ca.keyfile`` respectively.
   420  Both files must be PEM-encoded and must not be encrypted.
   421  More specifically, the contents of the CA certificate file must begin with ``-----BEGIN CERTIFICATE-----``
   422  and the contents of the key file must begin with ``-----BEGIN PRIVATE KEY-----`` and not
   423  ``-----BEGIN ENCRYPTED PRIVATE KEY-----``.
   424  
   425  Algorithms and key sizes
   426  
   427  The CSR can be customized to generate X.509 certificates and keys that
   428  support Elliptic Curve (ECDSA). The following setting is an
   429  example of the implementation of Elliptic Curve Digital Signature
   430  Algorithm (ECDSA) with curve ``prime256v1`` and signature algorithm
   431  ``ecdsa-with-SHA256``:
   432  
   433  .. code:: yaml
   434  
   435      key:
   436         algo: ecdsa
   437         size: 256
   438  
   439  The choice of algorithm and key size are based on security needs.
   440  
   441  Elliptic Curve (ECDSA) offers the following key size options:
   442  
   443  +--------+--------------+-----------------------+
   444  | size   | ASN1 OID     | Signature Algorithm   |
   445  +========+==============+=======================+
   446  | 256    | prime256v1   | ecdsa-with-SHA256     |
   447  +--------+--------------+-----------------------+
   448  | 384    | secp384r1    | ecdsa-with-SHA384     |
   449  +--------+--------------+-----------------------+
   450  | 521    | secp521r1    | ecdsa-with-SHA512     |
   451  +--------+--------------+-----------------------+
   452  
   453  Starting the server
   454  ~~~~~~~~~~~~~~~~~~~
   455  
   456  Start the Fabric CA server as follows:
   457  
   458  .. code:: bash
   459  
   460      fabric-ca-server start -b <admin>:<adminpw>
   461  
   462  If the server has not been previously initialized, it will initialize
   463  itself as it starts for the first time.  During this initialization, the
   464  server will generate the ca-cert.pem and ca-key.pem files if they don't
   465  yet exist and will also create a default configuration file if it does
   466  not exist.  See the `Initialize the Fabric CA server <#initialize>`__ section.
   467  
   468  Unless the Fabric CA server is configured to use LDAP, it must be
   469  configured with at least one pre-registered bootstrap identity to enable you
   470  to register and enroll other identities. The ``-b`` option specifies the
   471  name and password for a bootstrap identity.
   472  
   473  To cause the Fabric CA server to listen on ``https`` rather than
   474  ``http``, set ``tls.enabled`` to ``true``.
   475  
   476  To limit the number of times that the same secret (or password) can be
   477  used for enrollment, set the ``registry.maxenrollments`` in the configuration
   478  file to the appropriate value. If you set the value to 1, the Fabric CA
   479  server allows passwords to only be used once for a particular enrollment
   480  ID. If you set the value to -1, the Fabric CA server places no limit on
   481  the number of times that a secret can be reused for enrollment. The
   482  default value is -1. Setting the value to 0, the Fabric CA server will
   483  disable enrollment for all identitiies and registeration of identities will
   484  not be allowed.
   485  
   486  The Fabric CA server should now be listening on port 7054.
   487  
   488  You may skip to the `Fabric CA Client <#fabric-ca-client>`__ section if
   489  you do not want to configure the Fabric CA server to run in a cluster or
   490  to use LDAP.
   491  
   492  Configuring the database
   493  ~~~~~~~~~~~~~~~~~~~~~~~~
   494  
   495  This section describes how to configure the Fabric CA server to connect
   496  to PostgreSQL or MySQL databases. The default database is SQLite and the
   497  default database file is ``fabric-ca-server.db`` in the Fabric CA
   498  server's home directory.
   499  
   500  If you don't care about running the Fabric CA server in a cluster, you
   501  may skip this section; otherwise, you must configure either PostgreSQL or
   502  MySQL as described below. Fabric CA supports the following database
   503  versions in a cluster setup:
   504  
   505  - PostgreSQL: 9.5.5 or later
   506  - MySQL: 5.17.16 or later
   507  
   508  PostgreSQL
   509  ^^^^^^^^^^
   510  
   511  The following sample may be added to the server's configuration file in
   512  order to connect to a PostgreSQL database. Be sure to customize the
   513  various values appropriately. There are limitations on what characters are allowed
   514  in the database name. Please refer to the following Postgres documentation
   515  for more information: https://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
   516  
   517  .. code:: yaml
   518  
   519      db:
   520        type: postgres
   521        datasource: host=localhost port=5432 user=Username password=Password dbname=fabric_ca sslmode=verify-full
   522  
   523  Specifying *sslmode* configures the type of SSL authentication. Valid
   524  values for sslmode are:
   525  
   526  |
   527  
   528  +----------------+----------------+
   529  | Mode           | Description    |
   530  +================+================+
   531  | disable        | No SSL         |
   532  +----------------+----------------+
   533  | require        | Always SSL     |
   534  |                | (skip          |
   535  |                | verification)  |
   536  +----------------+----------------+
   537  | verify-ca      | Always SSL     |
   538  |                | (verify that   |
   539  |                | the            |
   540  |                | certificate    |
   541  |                | presented by   |
   542  |                | the server was |
   543  |                | signed by a    |
   544  |                | trusted CA)    |
   545  +----------------+----------------+
   546  | verify-full    | Same as        |
   547  |                | verify-ca AND  |
   548  |                | verify that    |
   549  |                | the            |
   550  |                | certificate    |
   551  |                | presented by   |
   552  |                | the server was |
   553  |                | signed by a    |
   554  |                | trusted CA and |
   555  |                | the server     |
   556  |                | hostname       |
   557  |                | matches the    |
   558  |                | one in the     |
   559  |                | certificate    |
   560  +----------------+----------------+
   561  
   562  |
   563  
   564  If you would like to use TLS, then the ``db.tls`` section in the Fabric CA server
   565  configuration file must be specified. If SSL client authentication is enabled
   566  on the PostgreSQL server, then the client certificate and key file must also be
   567  specified in the ``db.tls.client`` section. The following is an example
   568  of the ``db.tls`` section:
   569  
   570  .. code:: yaml
   571  
   572      db:
   573        ...
   574        tls:
   575            enabled: true
   576            certfiles:
   577              - db-server-cert.pem
   578            client:
   579                  certfile: db-client-cert.pem
   580                  keyfile: db-client-key.pem
   581  
   582  | **certfiles** - A list of PEM-encoded trusted root certificate files.
   583  | **certfile** and **keyfile** - PEM-encoded certificate and key files that are used by the Fabric CA server to communicate securely with the PostgreSQL server
   584  
   585  PostgreSQL SSL Configuration
   586  """""""""""""""""""""""""""""
   587  
   588  **Basic instructions for configuring SSL on the PostgreSQL server:**
   589  
   590  1. In postgresql.conf, uncomment SSL and set to "on" (SSL=on)
   591  
   592  2. Place certificate and key files in the PostgreSQL data directory.
   593  
   594  Instructions for generating self-signed certificates for:
   595  https://www.postgresql.org/docs/9.5/static/ssl-tcp.html
   596  
   597  Note: Self-signed certificates are for testing purposes and should not
   598  be used in a production environment
   599  
   600  **PostgreSQL Server - Require Client Certificates**
   601  
   602  1. Place certificates of the certificate authorities (CAs) you trust in the file root.crt in the PostgreSQL data directory
   603  
   604  2. In postgresql.conf, set "ssl\_ca\_file" to point to the root cert of the client (CA cert)
   605  
   606  3. Set the clientcert parameter to 1 on the appropriate hostssl line(s) in pg\_hba.conf.
   607  
   608  For more details on configuring SSL on the PostgreSQL server, please refer
   609  to the following PostgreSQL documentation:
   610  https://www.postgresql.org/docs/9.4/static/libpq-ssl.html
   611  
   612  MySQL
   613  ^^^^^^^
   614  
   615  The following sample may be added to the Fabric CA server configuration file in
   616  order to connect to a MySQL database. Be sure to customize the various
   617  values appropriately. There are limitations on what characters are allowed
   618  in the database name. Please refer to the following MySQL documentation
   619  for more information: https://dev.mysql.com/doc/refman/5.7/en/identifiers.html
   620  
   621  On MySQL 5.7.X, certain modes affect whether the server permits '0000-00-00' as a valid date.
   622  It might be necessary to relax the modes that MySQL server uses. We want to allow
   623  the server to be able to accept zero date values.
   624  
   625  In my.cnf, find the configuration option *sql_mode* and remove *NO_ZERO_DATE* if present.
   626  Restart MySQL server after making this change.
   627  
   628  Please refer to the following MySQL documentation on different modes available
   629  and select the appropriate settings for the specific version of MySQL that is
   630  being used.
   631  
   632  https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html
   633  
   634  On MySQL 5.7.X, certain modes affect whether the server permits '0000-00-00' as a valid date.
   635  It might be necessary to relax the modes that MySQL server uses. We want to allow
   636  the server to be able to accept zero date values.
   637  
   638  In my.cnf, find the configuration option *sql_mode* and remove *NO_ZERO_DATE* if present.
   639  Restart MySQL server after making this change.
   640  
   641  Please refer to the following MySQL documentation on different modes available
   642  and select the appropriate settings for the specific version of MySQL that is
   643  being used.
   644  
   645  https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html
   646  
   647  .. code:: yaml
   648  
   649      db:
   650        type: mysql
   651        datasource: root:rootpw@tcp(localhost:3306)/fabric_ca?parseTime=true&tls=custom
   652  
   653  If connecting over TLS to the MySQL server, the ``db.tls.client``
   654  section is also required as described in the **PostgreSQL** section above.
   655  
   656  MySQL SSL Configuration
   657  """"""""""""""""""""""""
   658  
   659  **Basic instructions for configuring SSL on MySQL server:**
   660  
   661  1. Open or create my.cnf file for the server. Add or uncomment the
   662     lines below in the [mysqld] section. These should point to the key and
   663     certificates for the server, and the root CA cert.
   664  
   665     Instructions on creating server and client-side certficates:
   666     http://dev.mysql.com/doc/refman/5.7/en/creating-ssl-files-using-openssl.html
   667  
   668     [mysqld] ssl-ca=ca-cert.pem ssl-cert=server-cert.pem ssl-key=server-key.pem
   669  
   670     Can run the following query to confirm SSL has been enabled.
   671  
   672     mysql> SHOW GLOBAL VARIABLES LIKE 'have\_%ssl';
   673  
   674     Should see:
   675  
   676     +----------------+----------------+
   677     | Variable_name  | Value          |
   678     +================+================+
   679     | have_openssl   | YES            |
   680     +----------------+----------------+
   681     | have_ssl       | YES            |
   682     +----------------+----------------+
   683  
   684  2. After the server-side SSL configuration is finished, the next step is
   685     to create a user who has a privilege to access the MySQL server over
   686     SSL. For that, log in to the MySQL server, and type:
   687  
   688     mysql> GRANT ALL PRIVILEGES ON *.* TO 'ssluser'@'%' IDENTIFIED BY
   689     'password' REQUIRE SSL; mysql> FLUSH PRIVILEGES;
   690  
   691     If you want to give a specific IP address from which the user will
   692     access the server change the '%' to the specific IP address.
   693  
   694  **MySQL Server - Require Client Certificates**
   695  
   696  Options for secure connections are similar to those used on the server side.
   697  
   698  -  ssl-ca identifies the Certificate Authority (CA) certificate. This
   699     option, if used, must specify the same certificate used by the server.
   700  -  ssl-cert identifies MySQL server's certificate.
   701  -  ssl-key identifies MySQL server's private key.
   702  
   703  Suppose that you want to connect using an account that has no special
   704  encryption requirements or was created using a GRANT statement that
   705  includes the REQUIRE SSL option. As a recommended set of
   706  secure-connection options, start the MySQL server with at least
   707  --ssl-cert and --ssl-key options. Then set the ``db.tls.certfiles`` property
   708  in the server configuration file and start the Fabric CA server.
   709  
   710  To require that a client certificate also be specified, create the
   711  account using the REQUIRE X509 option. Then the client must also specify
   712  proper client key and certificate files; otherwise, the MySQL server
   713  will reject the connection. To specify client key and certificate files
   714  for the Fabric CA server, set the ``db.tls.client.certfile``,
   715  and ``db.tls.client.keyfile`` configuration properties.
   716  
   717  Configuring LDAP
   718  ~~~~~~~~~~~~~~~~
   719  
   720  The Fabric CA server can be configured to read from an LDAP server.
   721  
   722  In particular, the Fabric CA server may connect to an LDAP server to do
   723  the following:
   724  
   725  -  authenticate an identity prior to enrollment
   726  -  retrieve an identity's attribute values which are used for authorization.
   727  
   728  Modify the LDAP section of the Fabric CA server's configuration file to configure the
   729  server to connect to an LDAP server.
   730  
   731  .. code:: yaml
   732  
   733      ldap:
   734         # Enables or disables the LDAP client (default: false)
   735         enabled: false
   736         # The URL of the LDAP server
   737         url: <scheme>://<adminDN>:<adminPassword>@<host>:<port>/<base>
   738         userfilter: <filter>
   739         attribute:
   740            # 'names' is an array of strings that identify the specific attributes
   741            # which are requested from the LDAP server.
   742            names: <LDAPAttrs>
   743            # The 'converters' section is used to convert LDAP attribute values
   744            # to fabric CA attribute values.
   745            #
   746            # For example, the following converts an LDAP 'uid' attribute
   747            # whose value begins with 'revoker' to a fabric CA attribute
   748            # named "hf.Revoker" with a value of "true" (because the expression
   749            # evaluates to true).
   750            #    converters:
   751            #       - name: hf.Revoker
   752            #         value: attr("uid") =~ "revoker*"
   753            #
   754            # As another example, assume a user has an LDAP attribute named
   755            # 'member' which has multiple values of "dn1", "dn2", and "dn3".
   756            # Further assume the following configuration.
   757            #    converters:
   758            #       - name: myAttr
   759            #         value: map(attr("member"),"groups")
   760            #    maps:
   761            #       groups:
   762            #          - name: dn1
   763            #            value: orderer
   764            #          - name: dn2
   765            #            value: peer
   766            # The value of the user's 'myAttr' attribute is then computed to be
   767            # "orderer,peer,dn3".  This is because the value of 'attr("member")' is
   768            # "dn1,dn2,dn3", and the call to 'map' with a 2nd argument of
   769            # "group" replaces "dn1" with "orderer" and "dn2" with "peer".
   770            converters:
   771              - name: <fcaAttrName>
   772                value: <fcaExpr>
   773            maps:
   774              <mapName>:
   775                  - name: <from>
   776                    value: <to>
   777  
   778  Where:
   779  
   780    * ``scheme`` is one of *ldap* or *ldaps*;
   781    * ``adminDN`` is the distinquished name of the admin user;
   782    * ``pass`` is the password of the admin user;
   783    * ``host`` is the hostname or IP address of the LDAP server;
   784    * ``port`` is the optional port number, where default 389 for *ldap*
   785      and 636 for *ldaps*;
   786    * ``base`` is the optional root of the LDAP tree to use for searches;
   787    * ``filter`` is a filter to use when searching to convert a login
   788      user name to a distinquished name. For example, a value of
   789      ``(uid=%s)`` searches for LDAP entries with the value of a ``uid``
   790      attribute whose value is the login user name. Similarly,
   791      ``(email=%s)`` may be used to login with an email address.
   792    * ``LDAPAttrs` is an array of LDAP attribute names to request from the
   793      LDAP server on a user's behalf;
   794    * the attribute.converters section is used to convert LDAP attributes to fabric
   795      CA attributes, where
   796      * ``fcaAttrName`` is the name of a fabric CA attribute;
   797      * ``fcaExpr`` is an expression whose evaluated value is assigned to
   798        the fabric CA attribute.
   799      For example, suppose that <LDAPAttrs> is ["uid"], <fcaAttrName> is 'hf.Revoker',
   800      and <fcaExpr> is 'attr("uid") =~ "revoker*"'.  This means that an attribute
   801      named "uid" is requested from the LDAP server on a user's behalf.  The user is
   802      then given a value of 'true' for the 'hf.Revoker' attribute if the value of
   803      the user's 'uid' LDAP attribute begins with 'revoker'; otherwise, the user
   804      is given a value of 'false' for the 'hf.Revoker' attribute.
   805    * the attribute.maps section is used to map LDAP response values.  The typical
   806      use case is to map a distinquished name associated with an LDAP group to an
   807      identity type.
   808  
   809  The LDAP expression language uses the govaluate package as described at
   810  https://github.com/Knetic/govaluate/blob/master/MANUAL.md.  This defines
   811  operators such as "=~" and literals such as "revoker*", which is a regular
   812  expression.  The LDAP-specific variables and functions which extend the
   813  base govaluate language are as follows.
   814    * ``DN`` is a variable equal to the user's distinguished name.
   815    * ``affiliation`` is a variable equal to the user's affiliation.
   816    * ``attr`` is a function which takes 1 or 2 arguments.  The 1st argument
   817      is an LDAP attribute name.  The 2nd argument is a separator string which is
   818      used to join multiple values into a single string; the default separator
   819      string is ",". The ``attr`` function always returns a value of type
   820      'string'.
   821    * ``map`` is a function which takes 2 arguments.  The 1st argument
   822      is any string.  The second argument is the name of a map which is used to
   823      perform string substitution on the string from the 1st argument.
   824    * ``if`` is a function which takes a 3 arguments where the first argument
   825      must resolve to a boolean value.  If it evaluates to true, the second
   826      argument is returned; otherwise, the third argument is returned.
   827  
   828  For example, the following expression evaluates to true if the user has
   829  a distinguished name ending in "O=org1,C=US", or if the user has an affiliation
   830  beginning with "org1.dept2." and also has the "admin" attribute of "true".
   831  
   832    **DN =~ "*O=org1,C=US" || (affiliation =~ "org1.dept2.*" && attr('admin') = 'true')**
   833  
   834  NOTE: Since the ``attr`` function always returns a value of type 'string',
   835  numeric operators may not be used to construct expressions.
   836  For example, the following is NOT a valid expression:
   837  
   838  .. code:: yaml
   839  
   840       value: attr("gidNumber) >= 10000 && attr("gidNumber) < 10006
   841  
   842  Alternatively, a regular expression enclosed in quotes as shown below may be used
   843  to return an equivalent result:
   844  
   845  .. code:: yaml
   846  
   847       value: attr("gidNumber") =~ "1000[0-5]$" || attr("mail") == "root@example.com"
   848  
   849  The following is a sample configuration section for the default setting
   850  for the OpenLDAP server whose docker image is at
   851  ``https://github.com/osixia/docker-openldap``.
   852  
   853  .. code:: yaml
   854  
   855      ldap:
   856         enabled: true
   857         url: ldap://cn=admin,dc=example,dc=org:admin@localhost:10389/dc=example,dc=org
   858         userfilter: (uid=%s)
   859  
   860  See ``FABRIC_CA/scripts/run-ldap-tests`` for a script which starts an
   861  OpenLDAP docker image, configures it, runs the LDAP tests in
   862  ``FABRIC_CA/cli/server/ldap/ldap_test.go``, and stops the OpenLDAP
   863  server.
   864  
   865  When LDAP is configured, enrollment works as follows:
   866  
   867  
   868  -  The Fabric CA client or client SDK sends an enrollment request with a
   869     basic authorization header.
   870  -  The Fabric CA server receives the enrollment request, decodes the
   871     identity name and password in the authorization header, looks up the DN (Distinquished
   872     Name) associated with the identity name using the "userfilter" from the
   873     configuration file, and then attempts an LDAP bind with the identity's
   874     password. If the LDAP bind is successful, the enrollment processing is
   875     authorized and can proceed.
   876  
   877  Setting up a cluster
   878  ~~~~~~~~~~~~~~~~~~~~
   879  
   880  You may use any IP sprayer to load balance to a cluster of Fabric CA
   881  servers. This section provides an example of how to set up Haproxy to
   882  route to a Fabric CA server cluster. Be sure to change hostname and port
   883  to reflect the settings of your Fabric CA servers.
   884  
   885  haproxy.conf
   886  
   887  .. code::
   888  
   889      global
   890            maxconn 4096
   891            daemon
   892  
   893      defaults
   894            mode http
   895            maxconn 2000
   896            timeout connect 5000
   897            timeout client 50000
   898            timeout server 50000
   899  
   900      listen http-in
   901            bind *:7054
   902            balance roundrobin
   903            server server1 hostname1:port
   904            server server2 hostname2:port
   905            server server3 hostname3:port
   906  
   907  
   908  Note: If using TLS, need to use ``mode tcp``.
   909  
   910  Setting up multiple CAs
   911  ~~~~~~~~~~~~~~~~~~~~~~~
   912  
   913  The fabric-ca server by default consists of a single default CA. However, additional CAs
   914  can be added to a single server by using `cafiles` or `cacount` configuration options.
   915  Each additional CA will have its own home directory.
   916  
   917  cacount:
   918  ^^^^^^^^
   919  
   920  The `cacount` provides a quick way to start X number of default additional
   921  CAs. The home directory will be relative to the server directory. With this option,
   922  the directory structure will be as follows:
   923  
   924  .. code:: yaml
   925  
   926      --<Server Home>
   927        |--ca
   928          |--ca1
   929          |--ca2
   930  
   931  Each additional CA will get a default configuration file generated in it's home
   932  directory, within the configuration file it will contain a unique CA name.
   933  
   934  For example, the following command will start 2 default CA instances:
   935  
   936  .. code:: bash
   937  
   938      fabric-ca-server start -b admin:adminpw --cacount 2
   939  
   940  cafiles:
   941  ^^^^^^^^
   942  
   943  If absolute paths are not provided when using the cafiles configuration option,
   944  the CA home directory will be relative to the server directory.
   945  
   946  To use this option, CA configuration files must have already been generated and
   947  configured for each CA that is to be started. Each configuration file must have
   948  a unique CA name and Common Name (CN), otherwise the server will fail to start as these
   949  names must be unique. The CA configuration files will override any default
   950  CA configuration, and any missing options in the CA configuration files will be
   951  replaced by the values from the default CA.
   952  
   953  The precedence order will be as follows:
   954  
   955    1. CA Configuration file
   956    2. Default CA CLI flags
   957    3. Default CA Environment variables
   958    4. Default CA Configuration file
   959  
   960  A CA configuration file must contain at least the following:
   961  
   962  .. code:: yaml
   963  
   964      ca:
   965      # Name of this CA
   966      name: <CANAME>
   967  
   968      csr:
   969        cn: <COMMONNAME>
   970  
   971  You may configure your directory structure as follows:
   972  
   973  .. code:: yaml
   974  
   975      --<Server Home>
   976        |--ca
   977          |--ca1
   978            |-- fabric-ca-config.yaml
   979          |--ca2
   980            |-- fabric-ca-config.yaml
   981  
   982  For example, the following command will start two customized CA instances:
   983  
   984  .. code:: bash
   985  
   986      fabric-ca-server start -b admin:adminpw --cafiles ca/ca1/fabric-ca-config.yaml
   987      --cafiles ca/ca2/fabric-ca-config.yaml
   988  
   989  Enrolling an intermediate CA
   990  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   991  
   992  In order to create a CA signing certificate for an intermediate CA, the intermediate
   993  CA must enroll with a parent CA in the same way that a fabric-ca-client enrolls with a CA.
   994  This is done by using the -u option to specify the URL of the parent CA and the enrollment ID
   995  and secret as shown below.  The identity associated with this enrollment ID must have an
   996  attribute with a name of "hf.IntermediateCA" and a value of "true".  The CN (or Common Name)
   997  of the issued certificate will be set to the enrollment ID. An error will occur if an intermediate
   998  CA tries to explicitly specify a CN value.
   999  
  1000  .. code:: bash
  1001  
  1002      fabric-ca-server start -b admin:adminpw -u http://<enrollmentID>:<secret>@<parentserver>:<parentport>
  1003  
  1004  For other intermediate CA flags see `Fabric CA server's configuration file format`_ section.
  1005  
  1006  `Back to Top`_
  1007  
  1008  .. _client:
  1009  
  1010  Fabric CA Client
  1011  ----------------
  1012  
  1013  This section describes how to use the fabric-ca-client command.
  1014  
  1015  The Fabric CA client's home directory is determined as follows:
  1016    - if the --home command line option is set, use its value
  1017    - otherwise, if the ``FABRIC_CA_CLIENT_HOME`` environment variable is set, use
  1018      its value
  1019    - otherwise, if the ``FABRIC_CA_HOME`` environment variable is set,
  1020      use its value
  1021    - otherwise, if the ``CA_CFG_PATH`` environment variable is set, use
  1022      its value
  1023    - otherwise, use ``$HOME/.fabric-ca-client``
  1024  
  1025  The instructions below assume that the client configuration file exists
  1026  in the client's home directory.
  1027  
  1028  Enrolling the bootstrap identity
  1029  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1030  
  1031  First, if needed, customize the CSR (Certificate Signing Request) section
  1032  in the client configuration file. Note that ``csr.cn`` field must be set
  1033  to the ID of the bootstrap identity. Default CSR values are shown below:
  1034  
  1035  .. code:: yaml
  1036  
  1037      csr:
  1038        cn: <<enrollment ID>>
  1039        key:
  1040          algo: ecdsa
  1041          size: 256
  1042        names:
  1043          - C: US
  1044            ST: North Carolina
  1045            L:
  1046            O: Hyperledger Fabric
  1047            OU: Fabric CA
  1048        hosts:
  1049         - <<hostname of the fabric-ca-client>>
  1050        ca:
  1051          pathlen:
  1052          pathlenzero:
  1053          expiry:
  1054  
  1055  See `CSR fields <#csr-fields>`__ for description of the fields.
  1056  
  1057  Then run ``fabric-ca-client enroll`` command to enroll the identity. For example,
  1058  following command enrolls an identity whose ID is **admin** and password is **adminpw**
  1059  by calling Fabric CA server that is running locally at 7054 port.
  1060  
  1061  .. code:: bash
  1062  
  1063      export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
  1064      fabric-ca-client enroll -u http://admin:adminpw@localhost:7054
  1065  
  1066  The enroll command stores an enrollment certificate (ECert), corresponding private key and CA
  1067  certificate chain PEM files in the subdirectories of the Fabric CA client's ``msp`` directory.
  1068  You will see messages indicating where the PEM files are stored.
  1069  
  1070  Registering a new identity
  1071  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1072  
  1073  The identity performing the register request must be currently enrolled, and
  1074  must also have the proper authority to register the type of the identity that is being
  1075  registered.
  1076  
  1077  In particular, three authorization checks are made by the Fabric CA server
  1078  during registration as follows:
  1079  
  1080   1. The registrar (i.e. the invoker) must have the "hf.Registrar.Roles" attribute with a
  1081      comma-separated list of values where one of the values equals the type of
  1082      identity being registered; for example, if the registrar has the
  1083      "hf.Registrar.Roles" attribute with a value of "peer,app,user", the registrar
  1084      can register identities of type peer, app, and user, but not orderer.
  1085  
  1086   2. The affiliation of the registrar must be equal to or a prefix of
  1087      the affiliation of the identity being registered.  For example, an registrar
  1088      with an affiliation of "a.b" may register an identity with an affiliation
  1089      of "a.b.c" but may not register an identity with an affiliation of "a.c".
  1090      If root affiliation is required for an identity, then the affiliation request
  1091      should be a dot (".") and the registrar must also have root affiliation.
  1092      If no affiliation is specified in the registration request, the identity being
  1093      registered will be given the affiliation of the registrar.
  1094  
  1095   3. The registrar can register a user with attributes if all of the following conditions
  1096      are satisfied:
  1097        - Registrar can register Fabric CA reserved attributes that have the prefix
  1098          'hf.' only if the registrar possesses the attribute and it is part of the value
  1099          of the 'hf.Registrar.Attributes' attribute. Furthermore, if the attribute
  1100          is of type list then the value of attribute being registered must be equal to or a subset
  1101          of the value that the registrar has. If the attribute is of type boolean, the registrar
  1102          can register the attribute only if the registrar's value for the attribute is 'true'.
  1103        - Registering custom attributes (i.e. any attribute whose name does not begin with 'hf.')
  1104          requires that the registrar has the 'hf.Registar.Attributes' attribute with the value of
  1105          the attribute or pattern being registered. The only supported pattern is a string with
  1106          a "*" at the end. For example, "a.b.*" is a pattern which matches all attribute names
  1107          beginning with "a.b.". For example, if the registrar has hf.Registrar.Attributes=orgAdmin,
  1108          then the only attribute which the registrar can add or remove from an identity is the 'orgAdmin'
  1109          attribute.
  1110        - If the requested attribute name is 'hf.Registrar.Attributes', an additional
  1111          check is performed to see if the requested values for this attribute
  1112          are equal to or a subset of the registrar's values for 'hf.Registrar.Attributes'.
  1113          For this to be true, each requested value must match a value in the registrar's
  1114          value for 'hf.Registrar.Attributes' attribute. For example, if the registrar's
  1115          value for 'hf.Registrar.Attributes' is 'a.b.*, x.y.z' and the requested attribute
  1116          value is 'a.b.c, x.y.z', it is valid because 'a.b.c' matches 'a.b.*' and 'x.y.z'
  1117          matches the registrar's 'x.y.z' value.
  1118  
  1119      Examples:
  1120        Valid Scenarios:
  1121          1. If the registrar has the attribute 'hf.Registrar.Attributes = a.b.*, x.y.z' and
  1122          is registering attribute 'a.b.c', it is valid 'a.b.c' matches 'a.b.*'.
  1123  
  1124          2. If the registrar has the attribute 'hf.Registrar.Attributes = a.b.*, x.y.z' and
  1125          is registering attribute 'x.y.z', it is valid because 'x.y.z' matches the registrar's
  1126          'x.y.z' value.
  1127  
  1128          3. If the registrar has the attribute 'hf.Registrar.Attributes = a.b.*, x.y.z' and
  1129          the requested attribute value is 'a.b.c, x.y.z', it is valid because 'a.b.c' matches
  1130          'a.b.*' and 'x.y.z' matches the registrar's 'x.y.z' value.
  1131  
  1132          4. If the registrar has the attribute 'hf.Registrar.Roles = peer,client' and
  1133          the requested attribute value is 'peer' or 'peer,client', it is valid because
  1134          the requested value is equal to or a subset of the registrar's value.
  1135  
  1136        Invalid Scenarios:
  1137          1. If the registrar has the attribute 'hf.Registrar.Attributes = a.b.*, x.y.z' and
  1138          is registering attribute 'hf.Registar.Attributes = a.b.c, x.y.*', it is invalid
  1139          because requested attribute 'x.y.*' is not a pattern owned by the registrar. The value
  1140          'x.y.*' is a superset of 'x.y.z'.
  1141  
  1142          2. If the registrar has the attribute 'hf.Registrar.Attributes = a.b.*, x.y.z' and
  1143          is registering attribute 'hf.Registar.Attributes = a.b.c, x.y.z, attr1', it is invalid
  1144          because the registrar's 'hf.Registrar.Attributes' attribute values do not contain 'attr1'.
  1145  
  1146          3. If the registrar has the attribute 'hf.Registrar.Attributes = a.b.*, x.y.z' and
  1147          is registering attribute 'a.b', it is invalid because the value 'a.b' is not contained in
  1148          'a.b.*'.
  1149  
  1150          4. If the registrar has the attribute 'hf.Registrar.Attributes = a.b.*, x.y.z' and
  1151          is registering attribute 'x.y', it is invalid because 'x.y' is not contained by 'x.y.z'.
  1152  
  1153          5. If the registrar has the attribute 'hf.Registrar.Roles = peer,client' and
  1154          the requested attribute value is 'peer,client,orderer', it is invalid because
  1155          the registrar does not have the orderer role in its value of hf.Registrar.Roles
  1156          attribue.
  1157  
  1158          6. If the registrar has the attribute 'hf.Revoker = false' and the requested attribute
  1159          value is 'true', it is invalid because the hf.Revoker attribute is a boolean attribute
  1160          and the registrar's value for the attribute is not 'true'.
  1161  
  1162  The table below lists all the attributes that can be registered for an identity.
  1163  
  1164  +-----------------------------+------------+------------------------------------------------------------------------------------------------------------+
  1165  | Name                        | Type       | Description                                                                                                |
  1166  +=============================+============+============================================================================================================+
  1167  | hf.Registrar.Roles          | List       | List of roles that the registrar is allowed to manage                                                      |
  1168  +-----------------------------+------------+------------------------------------------------------------------------------------------------------------+
  1169  | hf.Registrar.DelegateRoles  | List       | List of roles that the registrar is allowed to give to a registree for its 'hf.Registrar.Roles' attribute  |
  1170  +-----------------------------+------------+------------------------------------------------------------------------------------------------------------+
  1171  | hf.Registrar.Attributes     | List       | List of attributes that registrar is allowed to register                                                   |
  1172  +-----------------------------+------------+------------------------------------------------------------------------------------------------------------+
  1173  | hf.GenCRL                   | Boolean    | Identity is able to generate CRL if attribute value is true                                                |
  1174  +-----------------------------+------------+------------------------------------------------------------------------------------------------------------+
  1175  | hf.Revoker                  | Boolean    | Identity is able to revoke a user and/or certificates if attribute value is true                           |
  1176  +-----------------------------+------------+------------------------------------------------------------------------------------------------------------+
  1177  | hf.AffiliationMgr           | Boolean    | Identity is able to manage affiliations if attribute value is true                                         |
  1178  +-----------------------------+------------+------------------------------------------------------------------------------------------------------------+
  1179  | hf.IntermediateCA           | Boolean    | Identity is able to enroll as an intermediate CA if attribute value is true                                |
  1180  +-----------------------------+------------+------------------------------------------------------------------------------------------------------------+
  1181  
  1182  
  1183  The following command uses the **admin** identity's credentials to register a new
  1184  user with an enrollment id of "admin2", an affiliation of
  1185  "org1.department1", an attribute named "hf.Revoker" with a value of "true", and
  1186  an attribute named "admin" with a value of "true".  The ":ecert" suffix means that
  1187  by default the "admin" attribute and its value will be inserted into the user's
  1188  enrollment certificate, which can then be used to make access control decisions.
  1189  
  1190  .. code:: bash
  1191  
  1192      export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
  1193      fabric-ca-client register --id.name admin2 --id.affiliation org1.department1 --id.attrs 'hf.Revoker=true,admin=true:ecert'
  1194  
  1195  The password, also known as the enrollment secret, is printed.
  1196  This password is required to enroll the identity.
  1197  This allows an administrator to register an identity and give the
  1198  enrollment ID and the secret to someone else to enroll the identity.
  1199  
  1200  Multiple attributes can be specified as part of the --id.attrs flag, each
  1201  attribute must be comma separated. For an attribute value that contains a comma,
  1202  the attribute must be encapsulated in double quotes. See example below.
  1203  
  1204  .. code:: bash
  1205  
  1206      fabric-ca-client register -d --id.name admin2 --id.affiliation org1.department1 --id.attrs '"hf.Registrar.Roles=peer,user",hf.Revoker=true'
  1207  
  1208  or
  1209  
  1210  .. code:: bash
  1211  
  1212      fabric-ca-client register -d --id.name admin2 --id.affiliation org1.department1 --id.attrs '"hf.Registrar.Roles=peer,user"' --id.attrs hf.Revoker=true
  1213  
  1214  You may set default values for any of the fields used in the register command
  1215  by editing the client's configuration file.  For example, suppose the configuration
  1216  file contains the following:
  1217  
  1218  .. code:: yaml
  1219  
  1220      id:
  1221        name:
  1222        type: user
  1223        affiliation: org1.department1
  1224        maxenrollments: -1
  1225        attributes:
  1226          - name: hf.Revoker
  1227            value: true
  1228          - name: anotherAttrName
  1229            value: anotherAttrValue
  1230  
  1231  The following command would then register a new identity with an enrollment id of
  1232  "admin3" which it takes from the command line, and the remainder is taken from the
  1233  configuration file including the identity type: "user", affiliation: "org1.department1",
  1234  and two attributes: "hf.Revoker" and "anotherAttrName".
  1235  
  1236  .. code:: bash
  1237  
  1238      export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
  1239      fabric-ca-client register --id.name admin3
  1240  
  1241  To register an identity with multiple attributes requires specifying all attribute names and values
  1242  in the configuration file as shown above.
  1243  
  1244  Setting `maxenrollments` to 0 or leaving it out from the configuration will result in the identity
  1245  being registered to use the CA's max enrollment value. Furthermore, the max enrollment value for
  1246  an identity being registered cannot exceed the CA's max enrollment value. For example, if the CA's
  1247  max enrollment value is 5. Any new identity must have a value less than or equal to 5, and also
  1248  can't set it to -1 (infinite enrollments).
  1249  
  1250  Next, let's register a peer identity which will be used to enroll the peer in the following section.
  1251  The following command registers the **peer1** identity.  Note that we choose to specify our own
  1252  password (or secret) rather than letting the server generate one for us.
  1253  
  1254  .. code:: bash
  1255  
  1256      export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
  1257      fabric-ca-client register --id.name peer1 --id.type peer --id.affiliation org1.department1 --id.secret peer1pw
  1258  
  1259  Enrolling a peer identity
  1260  ~~~~~~~~~~~~~~~~~~~~~~~~~
  1261  
  1262  Now that you have successfully registered a peer identity, you may now
  1263  enroll the peer given the enrollment ID and secret (i.e. the *password*
  1264  from the previous section).  This is similar to enrolling the bootstrap identity
  1265  except that we also demonstrate how to use the "-M" option to populate the
  1266  Hyperledger Fabric MSP (Membership Service Provider) directory structure.
  1267  
  1268  The following command enrolls peer1.
  1269  Be sure to replace the value of the "-M" option with the path to your
  1270  peer's MSP directory which is the
  1271  'mspConfigPath' setting in the peer's core.yaml file.
  1272  You may also set the FABRIC_CA_CLIENT_HOME to the home directory of your peer.
  1273  
  1274  .. code:: bash
  1275  
  1276      export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/peer1
  1277      fabric-ca-client enroll -u http://peer1:peer1pw@localhost:7054 -M $FABRIC_CA_CLIENT_HOME/msp
  1278  
  1279  Enrolling an orderer is the same, except the path to the MSP directory is
  1280  the 'LocalMSPDir' setting in your orderer's orderer.yaml file.
  1281  
  1282  All enrollment certificates issued by the fabric-ca-server have organizational
  1283  units (or "OUs" for short) as follows:
  1284  
  1285  1. The root of the OU hierarchy equals the identity type
  1286  2. An OU is added for each component of the identity's affiliation
  1287  
  1288  For example, if an identity is of type `peer` and its affiliation is
  1289  `department1.team1`, the identity's OU hierarchy (from leaf to root) is
  1290  `OU=team1, OU=department1, OU=peer`.
  1291  
  1292  Getting a CA certificate chain from another Fabric CA server
  1293  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1294  
  1295  In general, the cacerts directory of the MSP directory must contain the certificate authority chains
  1296  of other certificate authorities, representing all of the roots of trust for the peer.
  1297  
  1298  The ``fabric-ca-client getcacerts`` command is used to retrieve these certificate chains from other
  1299  Fabric CA server instances.
  1300  
  1301  For example, the following will start a second Fabric CA server on localhost
  1302  listening on port 7055 with a name of "CA2".  This represents a completely separate
  1303  root of trust and would be managed by a different member on the blockchain.
  1304  
  1305  .. code:: bash
  1306  
  1307      export FABRIC_CA_SERVER_HOME=$HOME/ca2
  1308      fabric-ca-server start -b admin:ca2pw -p 7055 -n CA2
  1309  
  1310  The following command will install CA2's certificate chain into peer1's MSP directory.
  1311  
  1312  .. code:: bash
  1313  
  1314      export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/peer1
  1315      fabric-ca-client getcacert -u http://localhost:7055 -M $FABRIC_CA_CLIENT_HOME/msp
  1316  
  1317  By default, the Fabric CA server returns the CA chain in child-first order. This means that each CA
  1318  certificate in the chain is followed by its issuer's CA certificate. If you need the Fabric CA server
  1319  to return the CA chain in the opposite order, then set the environment variable ``CA_CHAIN_PARENT_FIRST``
  1320  to ``true`` and restart the Fabric CA server. The Fabric CA client will handle either order appropriately.
  1321  
  1322  Reenrolling an Identity
  1323  ~~~~~~~~~~~~~~~~~~~~~~~
  1324  
  1325  Suppose your enrollment certificate is about to expire or has been compromised.
  1326  You can issue the reenroll command to renew your enrollment certificate as follows.
  1327  
  1328  .. code:: bash
  1329  
  1330      export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/peer1
  1331      fabric-ca-client reenroll
  1332  
  1333  Revoking a certificate or identity
  1334  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1335  An identity or a certificate can be revoked. Revoking an identity will revoke all
  1336  the certificates owned by the identity and will also prevent the identity from getting
  1337  any new certificates. Revoking a certificate will invalidate a single certificate.
  1338  
  1339  In order to revoke a certificate or an identity, the calling identity must have
  1340  the ``hf.Revoker`` and ``hf.Registrar.Roles`` attribute. The revoking identity
  1341  can only revoke a certificate or an identity that has an affiliation that is
  1342  equal to or prefixed by the revoking identity's affiliation. Furthermore, the
  1343  revoker can only revoke identities with types that are listed in the revoker's
  1344  ``hf.Registrar.Roles`` attribute.
  1345  
  1346  For example, a revoker with affiliation **orgs.org1** and 'hf.Registrar.Roles=peer,client'
  1347  attribute can revoke either a **peer** or **client** type identity affiliated with
  1348  **orgs.org1** or **orgs.org1.department1** but can't revoke an identity affiliated with
  1349  **orgs.org2** or of any other type.
  1350  
  1351  The following command disables an identity and revokes all of the certificates
  1352  associated with the identity. All future requests received by the Fabric CA server
  1353  from this identity will be rejected.
  1354  
  1355  .. code:: bash
  1356  
  1357      fabric-ca-client revoke -e <enrollment_id> -r <reason>
  1358  
  1359  The following are the supported reasons that can be specified using ``-r`` flag:
  1360  
  1361    1. unspecified
  1362    2. keycompromise
  1363    3. cacompromise
  1364    4. affiliationchange
  1365    5. superseded
  1366    6. cessationofoperation
  1367    7. certificatehold
  1368    8. removefromcrl
  1369    9. privilegewithdrawn
  1370    10. aacompromise
  1371  
  1372  For example, the bootstrap admin who is associated with root of the affiliation tree
  1373  can revoke **peer1**'s identity as follows:
  1374  
  1375  .. code:: bash
  1376  
  1377      export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
  1378      fabric-ca-client revoke -e peer1
  1379  
  1380  An enrollment certificate that belongs to an identity can be revoked by
  1381  specifying its AKI (Authority Key Identifier) and serial number as follows:
  1382  
  1383  .. code:: bash
  1384  
  1385      fabric-ca-client revoke -a xxx -s yyy -r <reason>
  1386  
  1387  For example, you can get the AKI and the serial number of a certificate using the openssl command
  1388  and pass them to the ``revoke`` command to revoke the said certificate as follows:
  1389  
  1390  .. code:: bash
  1391  
  1392     serial=$(openssl x509 -in userecert.pem -serial -noout | cut -d "=" -f 2)
  1393     aki=$(openssl x509 -in userecert.pem -text | awk '/keyid/ {gsub(/ *keyid:|:/,"",$1);print tolower($0)}')
  1394     fabric-ca-client revoke -s $serial -a $aki -r affiliationchange
  1395  
  1396  The `--gencrl` flag can be used to generate a CRL (Certificate Revocation List) that contains all the revoked
  1397  certificates. For example, following command will revoke the identity **peer1**, generates a CRL and stores
  1398  it in the **<msp folder>/crls/crl.pem** file.
  1399  
  1400  .. code:: bash
  1401  
  1402      fabric-ca-client revoke -e peer1 --gencrl
  1403  
  1404  A CRL can also be generated using the `gencrl` command. Refer to the `Generating a CRL (Certificate Revocation List)`_
  1405  section for more information on the `gencrl` command.
  1406  
  1407  Generating a CRL (Certificate Revocation List)
  1408  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1409  After a certificate is revoked in the Fabric CA server, the appropriate MSPs in Hyperledger Fabric must also be updated.
  1410  This includes both local MSPs of the peers as well as MSPs in the appropriate channel configuration blocks.
  1411  To do this, PEM encoded CRL (certificate revocation list) file must be placed in the `crls`
  1412  folder of the MSP. The ``fabric-ca-client gencrl`` command can be used to generate a CRL. Any identity
  1413  with ``hf.GenCRL`` attribute can create a CRL that contains serial numbers of all certificates that were revoked
  1414  during a certain period. The created CRL is stored in the `<msp folder>/crls/crl.pem` file.
  1415  
  1416  The following command will create a CRL containing all the revoked certficates (expired and unexpired) and
  1417  store the CRL in the `~/msp/crls/crl.pem` file.
  1418  
  1419  .. code:: bash
  1420  
  1421      export FABRIC_CA_CLIENT_HOME=~/clientconfig
  1422      fabric-ca-client gencrl -M ~/msp
  1423  
  1424  The next command will create a CRL containing all certficates (expired and unexpired) that were revoked after
  1425  2017-09-13T16:39:57-08:00 (specified by the `--revokedafter` flag) and before 2017-09-21T16:39:57-08:00
  1426  (specified by the `--revokedbefore` flag) and store the CRL in the `~/msp/crls/crl.pem` file.
  1427  
  1428  .. code:: bash
  1429  
  1430      export FABRIC_CA_CLIENT_HOME=~/clientconfig
  1431      fabric-ca-client gencrl --caname "" --revokedafter 2017-09-13T16:39:57-08:00 --revokedbefore 2017-09-21T16:39:57-08:00 -M ~/msp
  1432  
  1433  
  1434  The `--caname` flag specifies the name of the CA to which this request is sent. In this example, the gencrl request is
  1435  sent to the default CA.
  1436  
  1437  The `--revokedafter` and `--revokedbefore` flags specify the lower and upper boundaries of a time period.
  1438  The generated CRL will contain certificates that were revoked in this time period. The values must be UTC
  1439  timestamps specified in RFC3339 format. The `--revokedafter` timestamp cannot be greater than the
  1440  `--revokedbefore` timestamp.
  1441  
  1442  By default, 'Next Update' date of the CRL is set to next day. The `crl.expiry` CA configuration property
  1443  can be used to specify a custom value.
  1444  
  1445  The gencrl command will also accept `--expireafter` and `--expirebefore` flags that can be used to generate a CRL
  1446  with revoked certificates that expire during the period specified by these flags. For example, the following command
  1447  will generate a CRL that contains certficates that were revoked after 2017-09-13T16:39:57-08:00 and
  1448  before 2017-09-21T16:39:57-08:00, and that expire after 2017-09-13T16:39:57-08:00 and before 2018-09-13T16:39:57-08:00
  1449  
  1450  .. code:: bash
  1451  
  1452      export FABRIC_CA_CLIENT_HOME=~/clientconfig
  1453      fabric-ca-client gencrl --caname "" --expireafter 2017-09-13T16:39:57-08:00 --expirebefore 2018-09-13T16:39:57-08:00  --revokedafter 2017-09-13T16:39:57-08:00 --revokedbefore 2017-09-21T16:39:57-08:00 -M ~/msp
  1454  
  1455  The `fabric-samples/fabric-ca <https://github.com/hyperledger/fabric-samples/blob/master/fabric-ca/scripts/run-fabric.sh>`_
  1456  sample demonstrates how to generate a CRL that contains certificate of a revoked user and update the channel
  1457  msp. It will then demonstrate that querying the channel using the revoked user credentials will result
  1458  in an authorization error.
  1459  
  1460  Enabling TLS
  1461  ~~~~~~~~~~~~
  1462  
  1463  This section describes in more detail how to configure TLS for a Fabric CA client.
  1464  
  1465  The following sections may be configured in the ``fabric-ca-client-config.yaml``.
  1466  
  1467  .. code:: yaml
  1468  
  1469      tls:
  1470        # Enable TLS (default: false)
  1471        enabled: true
  1472        certfiles:
  1473          - root.pem
  1474        client:
  1475          certfile: tls_client-cert.pem
  1476          keyfile: tls_client-key.pem
  1477  
  1478  The **certfiles** option is the set of root certificates trusted by the
  1479  client. This will typically just be the root Fabric CA server's
  1480  certificate found in the server's home directory in the **ca-cert.pem**
  1481  file.
  1482  
  1483  The **client** option is required only if mutual TLS is configured on
  1484  the server.
  1485  
  1486  Attribute-Based Access Control
  1487  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1488  
  1489  Access control decisions can be made by chaincode (and by the Hyperledger Fabric runtime)
  1490  based upon an identity's attributes.  This is called
  1491  **Attribute-Based Access Control**, or **ABAC** for short.
  1492  
  1493  In order to make this possible, an identity's enrollment certificate (ECert)
  1494  may contain one or more attribute name and value.  The chaincode then
  1495  extracts an attribute's value to make an access control decision.
  1496  
  1497  For example, suppose that you are developing application *app1* and want a
  1498  particular chaincode operation to be accessible only by app1 administrators.
  1499  Your chaincode could verify that the caller's certificate (which was issued by
  1500  a CA trusted for the channel) contains an attribute named *app1Admin* with a
  1501  value of *true*.  Of course the name of the attribute can be anything and the
  1502  value need not be a boolean value.
  1503  
  1504  So how do you get an enrollment certificate with an attribute?
  1505  There are two methods:
  1506  
  1507  1.   When you register an identity, you can specify that an enrollment certificate
  1508       issued for the identity should by default contain an attribute.  This behavior
  1509       can be overridden at enrollment time, but this is useful for establishing
  1510       default behavior and, assuming registration occurs outside of your application,
  1511       does not require any application change.
  1512  
  1513       The following shows how to register *user1* with two attributes:
  1514       *app1Admin* and *email*.
  1515       The ":ecert" suffix causes the *appAdmin* attribute to be inserted into user1's
  1516       enrollment certificate by default, when the user does not explicitly request
  1517       attributes at enrollment time.  The *email* attribute is not added
  1518       to the enrollment certificate by default.
  1519  
  1520  .. code:: bash
  1521  
  1522       fabric-ca-client register --id.name user1 --id.secret user1pw --id.type user --id.affiliation org1 --id.attrs 'app1Admin=true:ecert,email=user1@gmail.com'
  1523  
  1524  2. When you enroll an identity, you may explicitly request that one or more attributes
  1525     be added to the certificate.
  1526     For each attribute requested, you may specify whether the attribute is
  1527     optional or not.  If it is not requested optionally and the identity does
  1528     not possess the attribute, an error will occur.
  1529  
  1530     The following shows how to enroll *user1* with the *email* attribute,
  1531     without the *app1Admin* attribute, and optionally with the *phone*
  1532     attribute (if the user possesses the *phone* attribute).
  1533  
  1534  .. code:: bash
  1535  
  1536     fabric-ca-client enroll -u http://user1:user1pw@localhost:7054 --enrollment.attrs "email,phone:opt"
  1537  
  1538  The table below shows the three attributes which are automatically registered for every identity.
  1539  
  1540  ===================================   =====================================
  1541       Attribute Name                               Attribute Value
  1542  ===================================   =====================================
  1543    hf.EnrollmentID                        The enrollment ID of the identity
  1544    hf.Type                                The type of the identity
  1545    hf.Affiliation                         The affiliation of the identity
  1546  ===================================   =====================================
  1547  
  1548  To add any of the above attributes **by default** to a certificate, you must
  1549  explicitly register the attribute with the ":ecert" specification.
  1550  For example, the following registers identity 'user1' so that
  1551  the 'hf.Affiliation' attribute will be added to an enrollment certificate if
  1552  no specific attributes are requested at enrollment time.  Note that the
  1553  value of the affiliation (which is 'org1') must be the same in both the
  1554  '--id.affiliation' and the '--id.attrs' flags.
  1555  
  1556  .. code:: bash
  1557  
  1558      fabric-ca-client register --id.name user1 --id.secret user1pw --id.type user --id.affiliation org1 --id.attrs 'hf.Affiliation=org1:ecert'
  1559  
  1560  For information on the chaincode library API for Attribute-Based Access Control,
  1561  see https://github.com/hyperledger/fabric/tree/release/core/chaincode/lib/cid/README.md
  1562  
  1563  For an end-to-end sample which demonstrates Attribute-Based Access Control and more,
  1564  see https://github.com/hyperledger/fabric-samples/tree/release/fabric-ca/README.md
  1565  
  1566  Dynamic Server Configuration Update
  1567  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1568  
  1569  This section describes how to use fabric-ca-client to dynamically update portions
  1570  of the fabric-ca-server's configuration without restarting the server.
  1571  
  1572  All commands in this section require that you first be enrolled by executing the
  1573  `fabric-ca-client enroll` command.
  1574  
  1575  Dynamically updating identities
  1576  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  1577  
  1578  This section describes how to use fabric-ca-client to dynamically update identities.
  1579  
  1580  An authorization failure will occur if the client identity does not satisfy all of the following:
  1581  
  1582   - The client identity must possess the "hf.Registrar.Roles" attribute with a comma-separated list of
  1583     values where one of the values equals the type of identity being updated; for example, if the client's
  1584     identity has the "hf.Registrar.Roles" attribute with a value of "client,peer", the client can update
  1585     identities of type 'client' and 'peer', but not 'orderer'.
  1586  
  1587   - The affiliation of the client's identity must be equal to or a prefix of the affiliation of the identity
  1588     being updated.  For example, a client with an affiliation of "a.b" may update an identity with an affiliation
  1589     of "a.b.c" but may not update an identity with an affiliation of "a.c". If root affiliation is required for an
  1590     identity, then the update request should specify a dot (".") for the affiliation and the client must also have
  1591     root affiliation.
  1592  
  1593  The following shows how to add, modify, and remove an affiliation.
  1594  
  1595  Getting Identity Information
  1596  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  1597  
  1598  A caller may retrieve information on a identity from the fabric-ca server as long as the caller meets
  1599  the authorization requirements highlighted in the section above. The following command shows how to get an
  1600  identity.
  1601  
  1602  .. code:: bash
  1603  
  1604      fabric-ca-client identity list --id user1
  1605  
  1606  A caller may also request to retrieve information on all identities that it is authorized to see by
  1607  issuing the following command.
  1608  
  1609  .. code:: bash
  1610  
  1611      fabric-ca-client identity list
  1612  
  1613  Adding an identity
  1614  """""""""""""""""""
  1615  
  1616  The following adds a new identity for 'user1'. Adding a new identity performs the same action as registering an
  1617  identity via the 'fabric-ca-client register' command. There are two available methods for adding a new identity.
  1618  The first method is via the `--json` flag where you describe the identity in a JSON string.
  1619  
  1620  .. code:: bash
  1621  
  1622      fabric-ca-client identity add user1 --json '{"secret": "user1pw", "type": "user", "affiliation": "org1", "max_enrollments": 1, "attrs": [{"name": "hf.Revoker", "value": "true"}]}'
  1623  
  1624  The following adds a user with root affiliation. Note that an affiliation name of "." means the root affiliation.
  1625  
  1626  .. code:: bash
  1627  
  1628      fabric-ca-client identity add user1 --json '{"secret": "user1pw", "type": "user", "affiliation": ".", "max_enrollments": 1, "attrs": [{"name": "hf.Revoker", "value": "true"}]}'
  1629  
  1630  The second method for adding an identity is to use direct flags. See the example below for adding 'user1'.
  1631  
  1632  .. code:: bash
  1633  
  1634      fabric-ca-client identity add user1 --secret user1pw --type user --affiliation . --maxenrollments 1 --attrs hf.Revoker=true
  1635  
  1636  The table below lists all the fields of an identity and whether they are required or optional, and any default values they might have.
  1637  
  1638  +----------------+------------+------------------------+
  1639  | Fields         | Required   | Default Value          |
  1640  +================+============+========================+
  1641  | ID             | Yes        |                        |
  1642  +----------------+------------+------------------------+
  1643  | Secret         | No         |                        |
  1644  +----------------+------------+------------------------+
  1645  | Affiliation    | No         | Caller's Affiliation   |
  1646  +----------------+------------+------------------------+
  1647  | Type           | No         | client                 |
  1648  +----------------+------------+------------------------+
  1649  | Maxenrollments | No         | 0                      |
  1650  +----------------+------------+------------------------+
  1651  | Attributes     | No         |                        |
  1652  +----------------+------------+------------------------+
  1653  
  1654  
  1655  Modifying an identity
  1656  """"""""""""""""""""""
  1657  
  1658  There are two available methods for modifying an existing identity. The first method is via the `--json` flag where you describe
  1659  the modifications in to an identity in a JSON string. Multiple modifications can be made in a single request. Any element of an identity that
  1660  is not modified will retain its original value.
  1661  
  1662  NOTE: A maxenrollments value of "-2" specifies that the CA's max enrollment setting is to be used.
  1663  
  1664  The command below make multiple modification to an identity using the --json flag.
  1665  
  1666  .. code:: bash
  1667  
  1668      fabric-ca-client identity modify user1 --json '{"secret": "newPassword", "affiliation": ".", "attrs": [{"name": "hf.Regisrar.Roles", "value": "peer,client"},{"name": "hf.Revoker", "value": "true"}]}'
  1669  
  1670  The commands below make modifcations using direct flags. The following updates the enrollment secret (or password) for identity 'user1' to 'newsecret'.
  1671  
  1672  .. code:: bash
  1673  
  1674      fabric-ca-client identity modify user1 --secret newsecret
  1675  
  1676  The following updates the affiliation of identity 'user1' to 'org2'.
  1677  
  1678  .. code:: bash
  1679  
  1680      fabric-ca-client identity modify user1 --affiliation org2
  1681  
  1682  The following updates the type of identity 'user1' to 'peer'.
  1683  
  1684  .. code:: bash
  1685  
  1686      fabric-ca-client identity modify user1 --type peer
  1687  
  1688  
  1689  The following updates the maxenrollments of identity 'user1' to 5.
  1690  
  1691  .. code:: bash
  1692  
  1693      fabric-ca-client identity modify user1 --maxenrollments 5
  1694  
  1695  By specifying a maxenrollments value of '-2', the following causes identity 'user1' to use
  1696  the CA's max enrollment setting.
  1697  
  1698  .. code:: bash
  1699  
  1700      fabric-ca-client identity modify user1 --maxenrollments -2
  1701  
  1702  The following sets the value of the 'hf.Revoker' attribute for identity 'user1' to 'false'.
  1703  If the identity has other attributes, they are not changed.  If the identity did not previously
  1704  possess the 'hf.Revoker' attribute, the attribute is added to the identity. An attribute may
  1705  also be removed by specifiying no value for the attribute.
  1706  
  1707  .. code:: bash
  1708  
  1709      fabric-ca-client identity modify user1 --attrs hf.Revoker=false
  1710  
  1711  The following removes the 'hf.Revoker' attribute for user 'user1'.
  1712  
  1713  .. code:: bash
  1714  
  1715      fabric-ca-client identity modify user1 --attrs hf.Revoker=
  1716  
  1717  The following demonstrates that multiple options may be used in a single `fabric-ca-client identity modify`
  1718  command. In this case, both the secret and the type are updated for user 'user1'.
  1719  
  1720  .. code:: bash
  1721  
  1722      fabric-ca-client identity modify user1 --secret newpass --type peer
  1723  
  1724  Removing an identity
  1725  """""""""""""""""""""
  1726  
  1727  The following removes identity 'user1' and also revokes any certificates associated with the 'user1' identity.
  1728  
  1729  .. code:: bash
  1730  
  1731      fabric-ca-client identity remove user1
  1732  
  1733  Note: Removal of identities is disabled in the fabric-ca-server by default, but may be enabled
  1734  by starting the fabric-ca-server with the `--cfg.identities.allowremove` option.
  1735  
  1736  Dynamically updating affiliations
  1737  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  1738  
  1739  This section describes how to use fabric-ca-client to dynamically update affiliations. The
  1740  following shows how to add, modify, remove, and list an affiliation.
  1741  
  1742  Adding an affiliation
  1743  """""""""""""""""""""""
  1744  
  1745  An authorization failure will occur if the client identity does not satisfy all of the following:
  1746  
  1747    - The client identity must possess the attribute 'hf.AffiliationMgr' with a value of 'true'.
  1748    - The affiliation of the client identity must be hierarchically above the affiliation being updated.
  1749      For example, if the client's affiliation is "a.b", the client may add affiliation "a.b.c" but not
  1750      "a" or "a.b".
  1751  
  1752  The following adds a new affiliation named ‘org1.dept1’.
  1753  
  1754  .. code:: bash
  1755  
  1756      fabric-ca-client affiliation add org1.dept1
  1757  
  1758  Modifying an affiliation
  1759  """""""""""""""""""""""""
  1760  
  1761  An authorization failure will occur if the client identity does not satisfy all of the following:
  1762  
  1763    - The client identity must possess the attribute 'hf.AffiliationMgr' with a value of 'true'.
  1764    - The affiliation of the client identity must be hierarchically above the affiliation being updated.
  1765      For example, if the client's affiliation is "a.b", the client may add affiliation "a.b.c" but not
  1766      "a" or "a.b".
  1767    - If the '--force' option is true and there are identities which must be modified, the client
  1768      identity must also be authorized to modify the identity.
  1769  
  1770  The following renames the 'org2' affiliation to 'org3'.  It also renames any sub affiliations
  1771  (e.g. 'org2.department1' is renamed to 'org3.department1').
  1772  
  1773  .. code:: bash
  1774  
  1775      fabric-ca-client affiliation modify org2 --name org3
  1776  
  1777  If there are identities that are affected by the renaming of an affiliation, it will result in
  1778  an error unless the '--force' option is used. Using the '--force' option will update the affiliation
  1779  of identities that are affected to use the new affiliation name.
  1780  
  1781  .. code:: bash
  1782  
  1783      fabric-ca-client affiliation modify org1 --name org2 --force
  1784  
  1785  Removing an affiliation
  1786  """""""""""""""""""""""""
  1787  
  1788  An authorization failure will occur if the client identity does not satisfy all of the following:
  1789  
  1790    - The client identity must possess the attribute 'hf.AffiliationMgr' with a value of 'true'.
  1791    - The affiliation of the client identity must be hierarchically above the affiliation being updated.
  1792      For example, if the client's affiliation is "a.b", the client may remove affiliation "a.b.c" but not
  1793      "a" or "a.b".
  1794    - If the '--force' option is true and there are identities which must be modified, the client
  1795      identity must also be authorized to modify the identity.
  1796  
  1797  The following removes affiliation 'org2' and also any sub affiliations.
  1798  For example, if 'org2.dept1' is an affiliation below 'org2', it is also removed.
  1799  
  1800  .. code:: bash
  1801  
  1802      fabric-ca-client affiliation remove org2
  1803  
  1804  If there are identities that are affected by the removing of an affiliation, it will result
  1805  in an error unless the '--force' option is used. Using the '--force' option will also remove
  1806  all identities that are associated with that affiliation, and the certificates associated with
  1807  any of these identities.
  1808  
  1809  Note: Removal of affiliations is disabled in the fabric-ca-server by default, but may be enabled
  1810  by starting the fabric-ca-server with the `--cfg.affiliations.allowremove` option.
  1811  
  1812  Listing affiliation information
  1813  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  1814  
  1815  An authorization failure will occur if the client identity does not satisfy all of the following:
  1816  
  1817    - The client identity must possess the attribute 'hf.AffiliationMgr' with a value of 'true'.
  1818    - Affiliation of the client identity must be equal to or be hierarchically above the
  1819      affiliation being updated. For example, if the client's affiliation is "a.b",
  1820      the client may get affiliation information on "a.b" or "a.b.c" but not "a" or "a.c".
  1821  
  1822  The following command shows how to get a specific affiliation.
  1823  
  1824  .. code:: bash
  1825  
  1826      fabric-ca-client affiliation list --affiliation org2.dept1
  1827  
  1828  A caller may also request to retrieve information on all affiliations that it is authorized to see by
  1829  issuing the following command.
  1830  
  1831  .. code:: bash
  1832  
  1833      fabric-ca-client affiliation list
  1834  
  1835  Contact specific CA instance
  1836  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1837  
  1838  When a server is running multiple CA instances, requests can be directed to a
  1839  specific CA. By default, if no CA name is specified in the client request the
  1840  request will be directed to the default CA on the fabric-ca server. A CA name
  1841  can be specified on the command line of a client command as follows:
  1842  
  1843  .. code:: bash
  1844  
  1845      fabric-ca-client enroll -u http://admin:adminpw@localhost:7054 --caname <caname>
  1846  
  1847  `Back to Top`_
  1848  
  1849  HSM
  1850  ---
  1851  By default, the Fabric CA server and client store private keys in a PEM-encoded file,
  1852  but they can also be configured to store private keys in an HSM (Hardware Security Module)
  1853  via PKCS11 APIs. This behavior is configured in the BCCSP (BlockChain Crypto Service Provider)
  1854  section of the server’s or client’s configuration file.
  1855  
  1856  Configuring Fabric CA server to use softhsm2
  1857  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1858  
  1859  This section shows how to configure the Fabric CA server or client to use a software version
  1860  of PKCS11 called softhsm (see https://github.com/opendnssec/SoftHSMv2).
  1861  
  1862  After installing softhsm, create a token, label it “ForFabric”, set the pin to ‘98765432’
  1863  (refer to softhsm documentation).
  1864  
  1865  You can use both the config file and environment variables to configure BCCSP
  1866  For example, set the bccsp section of Fabric CA server configuration file as follows.
  1867  Note that the default field’s value is PKCS11.
  1868  
  1869  .. code:: yaml
  1870  
  1871    #############################################################################
  1872    # BCCSP (BlockChain Crypto Service Provider) section is used to select which
  1873    # crypto library implementation to use
  1874    #############################################################################
  1875    bccsp:
  1876      default: PKCS11
  1877      pkcs11:
  1878        Library: /usr/local/Cellar/softhsm/2.1.0/lib/softhsm/libsofthsm2.so
  1879        Pin: 98765432
  1880        Label: ForFabric
  1881        hash: SHA2
  1882        security: 256
  1883        filekeystore:
  1884          # The directory used for the software file-based keystore
  1885          keystore: msp/keystore
  1886  
  1887  And you can override relevant fields via environment variables as follows:
  1888  
  1889  FABRIC_CA_SERVER_BCCSP_DEFAULT=PKCS11
  1890  FABRIC_CA_SERVER_BCCSP_PKCS11_LIBRARY=/usr/local/Cellar/softhsm/2.1.0/lib/softhsm/libsofthsm2.so
  1891  FABRIC_CA_SERVER_BCCSP_PKCS11_PIN=98765432
  1892  FABRIC_CA_SERVER_BCCSP_PKCS11_LABEL=ForFabric
  1893  
  1894  `Back to Top`_
  1895  
  1896  File Formats
  1897  ------------
  1898  
  1899  Fabric CA server's configuration file format
  1900  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1901  
  1902  A default configuration file is created in the server's home directory
  1903  (see `Fabric CA Server <#server>`__ section for more info). The following
  1904  link shows a sample :doc:`Server configuration file <serverconfig>`.
  1905  
  1906  Fabric CA client's configuration file format
  1907  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1908  
  1909  A default configuration file is created in the client's home directory
  1910  (see `Fabric CA Client <#client>`__ section for more info). The following
  1911  link shows a sample :doc:`Client configuration file <clientconfig>`.
  1912  
  1913  `Back to Top`_
  1914  
  1915  Troubleshooting
  1916  ---------------
  1917  
  1918  1. If you see a ``Killed: 9`` error on OSX when trying to execute
  1919     ``fabric-ca-client`` or ``fabric-ca-server``, there is a long thread
  1920     describing this problem at https://github.com/golang/go/issues/19734.
  1921     The short answer is that to work around this issue, you can run the
  1922     following command::
  1923  
  1924      # sudo ln -s /usr/bin/true /usr/local/bin/dsymutil
  1925  
  1926  2. The error ``[ERROR] No certificates found for provided serial and aki`` will occur
  1927     if the following sequence of events occurs:
  1928  
  1929     a. You issue a `fabric-ca-client enroll` command, creating an enrollment certificate (i.e. an ECert).
  1930        This stores a copy of the ECert in the fabric-ca-server's database.
  1931     b. The fabric-ca-server's database is deleted and recreated, thus losing the ECert from step 'a'.
  1932        For example, this may happen if you stop and restart a docker container hosting the fabric-ca-server,
  1933        but your fabric-ca-server is using the default sqlite database and the database file is not stored
  1934        on a volume and is therefore not persistent.
  1935     c. You issue a `fabric-ca-client register` command or any other command which tries to use the ECert from
  1936        step 'a'.  In this case, since the database no longer contains the ECert, the
  1937        ``[ERROR] No certificates found for provided serial and aki`` will occur.
  1938  
  1939     To resolve this error, you must enroll again by repeating step 'a'.  This will issue a new ECert
  1940     which will be stored in the current database.
  1941  
  1942  3. When sending multiple parallel requests to a Fabric CA Server cluster that uses shared sqlite3 databases,
  1943     the server occasionally returns a 'database locked' error. This is most probably because the database
  1944     transaction timed out while waiting for database lock (held by another cluster member) to be released.
  1945     This is an invalid configuration because sqlite is an embedded database, which means the Fabric CA server
  1946     cluster must share the same file via a shared file system, which introduces a SPoF (single point of failure),
  1947     which contradicts the purpose of cluster topology. The best practice is to use either Postgres or MySQL
  1948     databases in a cluster topology.
  1949  
  1950  4. Suppose an error similar to
  1951     ``Failed to deserialize creator identity, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority``
  1952     is returned by a peer or orderer when using an enrollment certificate issued by the Fabric CA Server.  This indicates that
  1953     the signing CA certificate used by the Fabric CA Server to issue certificates does not match a certificate in the `cacerts` or `intermediatecerts`
  1954     folder of the MSP used to make authorization checks.
  1955  
  1956     The MSP which is used to make authorization checks depends on which operation you were performing when the error occurred.
  1957     For example, if you were trying to install chaincode on a peer, the local MSP on the file system of the peer is used;
  1958     otherwise, if you were performing some channel specific operation such as instantiating chaincode on a specific channel,
  1959     the MSP in the genesis block or the most recent configuration block of the channel is used.
  1960  
  1961     To confirm that this is the problem, compare the AKI (Authority Key Identifier) of the enrollment certificate
  1962     to the SKI (Subject Key Identifier) of the certificate(s) in the `cacerts` and `intermediatecerts` folder of appropriate MSP.
  1963     The command `openssl x509 -in <PEM-file> -noout -text | grep -A1 "Authority Key Identifier"` will display the AKI and
  1964     `openssl x509 -in <PEM-file> -noout -text | grep -A1 "Subject Key Identifier"` will display the SKI.
  1965     If they are not equal, you have confirmed that this is the cause of the error.
  1966  
  1967     This can happen for multiple reasons including:
  1968  
  1969     a. You used `cryptogen` to generate your key material but did not start `fabric-ca-server` with the signing key and certificate generated
  1970        by `cryptogen`.
  1971  
  1972        To resolve (assuming `FABRIC_CA_SERVER_HOME` is set to the home directory of your `fabric-ca-server`):
  1973  
  1974        1. Stop `fabric-ca-server`.
  1975        2. Copy `crypto-config/peerOrganizations/<orgName>/ca/*pem` to `$FABRIC_CA_SERVER_HOME/ca-cert.pem`.
  1976        3. Copy `crypto-config/peerOrganizations/<orgName>/ca/*_sk` to `$FABRIC_CA_SERVER_HOME/msp/keystore/`.
  1977        4. Start `fabric-ca-server`.
  1978        5. Delete any previously issued enrollment certificates and get new certificates by enrolling again.
  1979  
  1980     b. You deleted and recreated the CA signing key and certificate used by the Fabric CA Server after generating the genesis block.
  1981        This can happen if the Fabric CA Server is running in a docker container, the container was restarted, and its home directory
  1982        is not on a volume mount.  In this case, the Fabric CA Server will create a new CA signing key and certificate.
  1983  
  1984        Assuming that you can not recover the original CA signing key, the only way to recover from this scenario is to update the
  1985        certificate in the `cacerts` (or `intermediatecerts`) of the appropriate MSPs to the new CA certificate.
  1986  
  1987  .. Licensed under Creative Commons Attribution 4.0 International License
  1988     https://creativecommons.org/licenses/by/4.0/