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/