diff --git a/doc/source/admin/remote-console-access.rst b/doc/source/admin/remote-console-access.rst index f5a2f01556..b8a48c22b8 100644 --- a/doc/source/admin/remote-console-access.rst +++ b/doc/source/admin/remote-console-access.rst @@ -2,77 +2,32 @@ Configure remote console access =============================== -To provide a remote console or remote desktop access to guest virtual machines, -use VNC, SPICE HTML5 or Serial through either the OpenStack dashboard or the -command line. Best practice is to select only one of them to run. +OpenStack provides a number of different methods to interact with your guests: +VNC, SPICE, Serial, RDP or MKS. If configured, these can be accessed by users +through the OpenStack dashboard or the command line. This document outlines how +these different technologies can be configured -.. _about-nova-consoleauth: -About nova-consoleauth ----------------------- +Overview +-------- -The client proxies leverage a shared service to manage token authentication -called ``nova-consoleauth``. This service must be running for either proxy to -work. Many proxies of either type can be run against a single -``nova-consoleauth`` service in a cluster configuration. +It is considered best practice to deploy only one of the consoles types and +not all console types are supported by all compute drivers. Regardless of what +option is chosen, a console proxy service is required. These proxy services are +responsible for the following: -Do not confuse the ``nova-consoleauth`` shared service with ``nova-console``, -which is a XenAPI-specific service that most recent VNC proxy architectures do -not use. +- Provide a bridge between the public network where the clients live and the + private network where the servers with consoles live. -.. deprecated:: 18.0.0 +- Mediate token authentication. - ``nova-consoleauth`` is deprecated since 18.0.0 (Rocky) and will be removed - in an upcoming release. +- Transparently handle hypervisor-specific connection details to provide a + uniform client experience. -SPICE console -------------- - -OpenStack Compute supports VNC consoles to guests. The VNC protocol is fairly -limited, lacking support for multiple monitors, bi-directional audio, reliable -cut-and-paste, video streaming and more. SPICE is a new protocol that aims to -address the limitations in VNC and provide good remote desktop support. - -SPICE support in OpenStack Compute shares a similar architecture to the VNC -implementation. The OpenStack dashboard uses a SPICE-HTML5 widget in its -console tab that communicates to the ``nova-spicehtml5proxy`` service by using -SPICE-over-websockets. The ``nova-spicehtml5proxy`` service communicates -directly with the hypervisor process by using SPICE. - -VNC must be explicitly disabled to get access to the SPICE console. Set the -``vnc_enabled`` option to ``False`` in the ``[DEFAULT]`` section to disable the -VNC console. - -Use the following options to configure SPICE as the console for OpenStack -Compute: - -.. code-block:: console - - [spice] - agent_enabled = False - enabled = True - html5proxy_base_url = http://IP_ADDRESS:6082/spice_auto.html - html5proxy_host = 0.0.0.0 - html5proxy_port = 6082 - keymap = en-us - server_listen = 127.0.0.1 - server_proxyclient_address = 127.0.0.1 - -Replace ``IP_ADDRESS`` with the management interface IP address of the -controller or the VIP. - -VNC console proxy ------------------ - -The VNC proxy is an OpenStack component that enables compute service users to -access their instances through VNC clients. - -.. note:: - - The web proxy console URLs do not support the websocket protocol scheme - (ws://) on python versions less than 2.7.4. - -The VNC console connection works as follows: +For some combinations of compute driver and console driver, these proxy +services are provided by the hypervisor or another service. For all others, +nova provides services to handle this proxying. Consider a noVNC-based VNC +console connection for example: #. A user connects to the API and gets an ``access_url`` such as, ``http://ip:port/?token=xyz``. @@ -81,33 +36,149 @@ The VNC console connection works as follows: #. The browser or client connects to the proxy. -#. The proxy talks to ``nova-consoleauth`` to authorize the token for the user, - and maps the token to the *private* host and port of the VNC server for an - instance. +#. The proxy talks to :program:`nova-consoleauth` to authorize the token for + the user, and maps the token to the *private* host and port of the VNC + server for an instance. The compute host specifies the address that the proxy should use to connect - through the ``nova.conf`` file option, ``server_proxyclient_address``. In + through the :oslo.config:option:`vnc.server_proxyclient_address` option. In this way, the VNC proxy works as a bridge between the public network and private host network. #. The proxy initiates the connection to VNC server and continues to proxy until the session ends. -The proxy also tunnels the VNC protocol over WebSockets so that the ``noVNC`` -client can talk to VNC servers. In general, the VNC proxy: +This means a typical deployment with noVNC-based VNC consoles will have the +following components: -- Bridges between the public network where the clients live and the private - network where VNC servers live. +- An instance of the :program:`nova-consoleauth` service. Typically runs on the + controller host. -- Mediates token authentication. +- One or more :program:`nova-novncproxy` service. Supports browser-based noVNC + clients. For simple deployments, this service typically runs on the same + machine as :program:`nova-api` because it operates as a proxy between the + public network and the private compute host network. -- Transparently deals with hypervisor-specific connection details to provide a - uniform client experience. +- One or more :program:`nova-compute` services. Hosts the instances for which + consoles are provided. + +This particular example is illustrated below. .. figure:: figures/SCH_5009_V00_NUAC-VNC_OpenStack.png :alt: noVNC process :width: 95% + +.. _about-nova-consoleauth: + +About ``nova-consoleauth`` +-------------------------- + +The :doc:`/cli/nova-consoleauth` service provides a shared service to manage +token authentication that the client proxies outlined below can leverage. This +service must be running for either proxy to work. Many proxies of either type +can be run against a single :program:`nova-consoleauth` service in a cluster +configuration. + +.. important:: + + Do not confuse the :program:`nova-consoleauth` shared service with + :doc:`/cli/nova-console` service, which is a XenAPI-specific service that + most recent VNC proxy architectures do not use. + +.. deprecated:: 18.0.0 + + ``nova-consoleauth`` is deprecated since 18.0.0 (Rocky) and will be removed + in an upcoming release. + + +noVNC-based VNC console +----------------------- + +VNC is a graphical console with wide support among many hypervisors and +clients. noVNC provides VNC support through a web browser. + +.. note:: + + It has `been reported`__ that versions of noVNC older than 0.6 do not work + with the :program:`nova-novncproxy` service. + + If using non-US key mappings, you need at least noVNC 1.0.0 for `a fix`__. + + __ https://bugs.launchpad.net/nova/+bug/1752896 + __ https://github.com/novnc/noVNC/commit/99feba6ba8fee5b3a2b2dc99dc25e9179c560d31 + +Configuration +~~~~~~~~~~~~~ + +To enable the noVNC VNC console service, you must configure both the +:program:`nova-novncproxy` service and the :program:`nova-compute` service. +Most options are defined in the :oslo.config:group:`vnc` group. + +The :program:`nova-novncproxy` service accepts the following options. + +- :oslo.config:option:`daemon` +- :oslo.config:option:`ssl_only` +- :oslo.config:option:`source_is_ipv6` +- :oslo.config:option:`cert` +- :oslo.config:option:`key` +- :oslo.config:option:`web` +- :oslo.config:option:`vnc.novncproxy_host` +- :oslo.config:option:`vnc.novncproxy_port` + +In addition, if using the libvirt compute driver and enabling +:ref:`vnc-security`, the following additional options are accepted. + +- :oslo.config:option:`vnc.auth_schemes` +- :oslo.config:option:`vnc.vencrypt_client_key` +- :oslo.config:option:`vnc.vencrypt_client_cert` +- :oslo.config:option:`vnc.vencrypt_ca_certs` + +Similarly, if using the VMware compute driver, the following additional options +are accepted. + +- :oslo.config:option:`vmware.vnc_port` +- :oslo.config:option:`vmware.vnc_port_total` + +For example, to configure this via a ``nova-novncproxy.conf`` file: + +.. code-block:: console + + [vnc] + novncproxy_host = 0.0.0.0 + novncproxy_port = 6082 + +.. note:: + + This doesn't show configuration with security. For information on how to + configure this, refer to :ref:`vnc-security` below. + +The :program:`nova-compute` service requires the following options to configure +noVNC-based VNC console support. + +- :oslo.config:option:`vnc.enabled` +- :oslo.config:option:`vnc.novncproxy_base_url` +- :oslo.config:option:`vnc.server_listen` +- :oslo.config:option:`vnc.server_proxyclient_address` +- :oslo.config:option:`vnc.keymap` + +For example, to configure this via a ``nova.conf`` file: + +.. code-block:: console + + [vnc] + enabled = True + novncproxy_base_url = http://IP_ADDRESS:6082/vnc_auto.html + server_listen = 127.0.0.1 + server_proxyclient_address = 127.0.0.1 + keymap = en-us + +Replace ``IP_ADDRESS`` with the IP address from which the proxy is accessible +by the outside world. For example, this may be the management interface IP +address of the controller or the VIP. + +.. _vnc-security: + VNC proxy security ~~~~~~~~~~~~~~~~~~ @@ -142,7 +213,7 @@ certificates: The authority certificate used to sign ``server-cert.pem`` and sign the VNC proxy server certificates. -The certificates must have v3 basic constraints [3]_ present to indicate the +The certificates must have v3 basic constraints [2]_ present to indicate the permitted key use and purpose data. We recommend using a dedicated certificate authority solely for the VNC @@ -151,7 +222,7 @@ for the OpenStack deployment. This is because libvirt does not currently have a mechanism to restrict what certificates can be presented by the proxy server. For further details on certificate creation, consult the QEMU manual page -documentation on VNC server certificate setup [2]_. +documentation on VNC server certificate setup [1]_. Configure libvirt to enable the VeNCrypt authentication scheme for the VNC server. In :file:`/etc/libvirt/qemu.conf`, uncomment the following settings: @@ -224,7 +295,7 @@ certificates to the noVNC proxy. The certificate authority cert used to sign ``client-cert.pem`` and sign the compute node VNC server certificates. -The certificates must have v3 basic constraints [3]_ present to indicate the +The certificates must have v3 basic constraints [2]_ present to indicate the permitted key use and purpose data. Once the certificates have been created, the noVNC console proxy service must @@ -237,161 +308,234 @@ be told where to find them. This requires editing :file:`nova.conf` to set. vencrypt_client_cert=/etc/pki/nova-novncproxy/client-cert.pem vencrypt_ca_certs=/etc/pki/nova-novncproxy/ca-cert.pem -VNC configuration options -~~~~~~~~~~~~~~~~~~~~~~~~~ -To customize the VNC console, use the following configuration options in your -``nova.conf`` file: +XVP-based VNC console +--------------------- -.. note:: +VNC is a graphical console with wide support among many hypervisors and +clients. Xen VNC Proxy (XVP) provides VNC support via a simple Java client. - To support :ref:`live migration `, - you cannot specify a specific IP address for ``server_listen``, because - that IP address does not exist on the destination host. +Configuration +~~~~~~~~~~~~~ -.. list-table:: **Description of VNC configuration options** - :header-rows: 1 - :widths: 25 25 +To enable the XVP VNC console service, you must configure both the +:program:`nova-xvpvncproxy` service and the :program:`nova-compute` service. +Most options are defined in the :oslo.config:group:`vnc` group. - * - Configuration option = Default value - - Description - * - **[DEFAULT]** - - - * - ``daemon = False`` - - (BoolOpt) Become a daemon (background process) - * - ``key = None`` - - (StrOpt) SSL key file (if separate from cert) - * - ``novncproxy_host = 0.0.0.0`` - - (StrOpt) Host on which to listen for incoming requests - * - ``novncproxy_port = 6080`` - - (IntOpt) Port on which to listen for incoming requests - * - ``record = False`` - - (BoolOpt) Record sessions to FILE.[session_number] - * - ``source_is_ipv6 = False`` - - (BoolOpt) Source is ipv6 - * - ``ssl_only = False`` - - (BoolOpt) Disallow non-encrypted connections - * - ``web = /usr/share/spice-html5`` - - (StrOpt) Run webserver on same port. Serve files from DIR. - * - **[vmware]** - - - * - ``vnc_port = 5900`` - - (IntOpt) VNC starting port - * - ``vnc_port_total = 10000`` - - vnc_port_total = 10000 - * - **[vnc]** - - - * - enabled = True - - (BoolOpt) Enable VNC related features - * - novncproxy_base_url = http://127.0.0.1:6080/vnc_auto.html - - (StrOpt) Location of VNC console proxy, in the form - "http://127.0.0.1:6080/vnc_auto.html" - * - server_listen = 127.0.0.1 - - (StrOpt) IP address on which instance vncservers should listen - * - server_proxyclient_address = 127.0.0.1 - - (StrOpt) The address to which proxy clients (like nova-xvpvncproxy) - should connect - * - xvpvncproxy_base_url = http://127.0.0.1:6081/console - - (StrOpt) Location of nova xvp VNC console proxy, in the form - "http://127.0.0.1:6081/console" +The :program:`nova-xvpvncproxy` service accepts the following options. -.. note:: +- :oslo.config:option:`daemon` +- :oslo.config:option:`ssl_only` +- :oslo.config:option:`source_is_ipv6` +- :oslo.config:option:`cert` +- :oslo.config:option:`key` +- :oslo.config:option:`web` +- :oslo.config:option:`vnc.xvpvncproxy_host` +- :oslo.config:option:`vnc.xvpvncproxy_port` - - The ``server_proxyclient_address`` defaults to ``127.0.0.1``, which is - the address of the compute host that Compute instructs proxies to use when - connecting to instance servers. - - - For all-in-one XenServer domU deployments, set this to ``169.254.0.1.`` - - - For multi-host XenServer domU deployments, set to a ``dom0 management IP`` - on the same network as the proxies. - - - For multi-host libvirt deployments, set to a host management IP on the - same network as the proxies. - -Typical deployment -~~~~~~~~~~~~~~~~~~ - -A typical deployment has the following components: - -- A ``nova-consoleauth`` process. Typically runs on the controller host. - -- One or more ``nova-novncproxy`` services. Supports browser-based noVNC - clients. For simple deployments, this service typically runs on the same - machine as ``nova-api`` because it operates as a proxy between the public - network and the private compute host network. - -- One or more ``nova-xvpvncproxy`` services. Supports the special Java client - discussed here. For simple deployments, this service typically runs on the - same machine as ``nova-api`` because it acts as a proxy between the public - network and the private compute host network. - -- One or more compute hosts. These compute hosts must have correctly configured - options, as follows. - -nova-novncproxy (noVNC) -~~~~~~~~~~~~~~~~~~~~~~~ - -You must install the noVNC package, which contains the ``nova-novncproxy`` -service. As root, run the following command: +For example, to configure this via a ``nova-xvpvncproxy.conf`` file: .. code-block:: console - # apt-get install nova-novncproxy + [vnc] + xvpvncproxy_host = 0.0.0.0 + xvpvncproxy_port = 6081 -.. note:: +The :program:`nova-compute` service requires the following options to configure +XVP-based VNC support. - It has `been reported`_ that versions of noVNC older than 0.6 do not work - with the ``nova-novncproxy`` service. +- :oslo.config:option:`vnc.enabled` +- :oslo.config:option:`vnc.xvpvncproxy_base_url` +- :oslo.config:option:`vnc.server_listen` +- :oslo.config:option:`vnc.server_proxyclient_address` +- :oslo.config:option:`vnc.keymap` - If using non-US key mappings, then you need at least noVNC 1.0.0 for `a fix - `_. - -.. _been reported: https://bugs.launchpad.net/nova/+bug/1752896 - -The service starts automatically on installation. - -To restart the service, run: +For example, to configure this via a ``nova.conf`` file: .. code-block:: console - # service nova-novncproxy restart + [vnc] + enabled = True + xvpvncproxy_base_url = http://IP_ADDRESS:6081/console + server_listen = 127.0.0.1 + server_proxyclient_address = 127.0.0.1 + keymap = en-us -The configuration option parameter should point to your ``nova.conf`` file, -which includes the message queue server address and credentials. +Replace ``IP_ADDRESS`` with the IP address from which the proxy is accessible +by the outside world. For example, this may be the management interface IP +address of the controller or the VIP. -By default, ``nova-novncproxy`` binds on ``0.0.0.0:6080``. -To connect the service to your Compute deployment, add the following -configuration options to your ``nova.conf`` file: +SPICE console +------------- -- ``server_listen=0.0.0.0`` +The VNC protocol is fairly limited, lacking support for multiple monitors, +bi-directional audio, reliable cut-and-paste, video streaming and more. SPICE +is a new protocol that aims to address the limitations in VNC and provide good +remote desktop support. - Specifies the address on which the VNC service should bind. Make sure it is - assigned one of the compute node interfaces. This address is the one used by - your domain file. +SPICE support in OpenStack Compute shares a similar architecture to the VNC +implementation. The OpenStack dashboard uses a SPICE-HTML5 widget in its +console tab that communicates with the :program:`nova-spicehtml5proxy` service +by using SPICE-over-websockets. The :program:`nova-spicehtml5proxy` service +communicates directly with the hypervisor process by using SPICE. - .. code-block:: console +Configuration +~~~~~~~~~~~~~ - +.. important:: - .. note:: + VNC must be explicitly disabled to get access to the SPICE console. Set the + :oslo.config:option:`vnc.enabled` option to ``False`` to disable the + VNC console. - To use live migration, use the 0.0.0.0 address. +To enable the SPICE console service, you must configure both the +:program:`nova-spicehtml5proxy` service and the :program:`nova-compute` +service. Most options are defined in the :oslo.config:group:`spice` group. -- ``server_proxyclient_address=127.0.0.1`` +The :program:`nova-spicehtml5proxy` service accepts the following options. - The address of the compute host that Compute instructs proxies to use when - connecting to instance ``vncservers``. +- :oslo.config:option:`daemon` +- :oslo.config:option:`ssl_only` +- :oslo.config:option:`source_is_ipv6` +- :oslo.config:option:`cert` +- :oslo.config:option:`key` +- :oslo.config:option:`web` +- :oslo.config:option:`spice.html5proxy_host` +- :oslo.config:option:`spice.html5proxy_port` -Frequently asked questions about VNC access to virtual machines -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For example, to configure this via a ``nova-spicehtml5proxy.conf`` file: + +.. code-block:: console + + [spice] + html5proxy_host = 0.0.0.0 + html5proxy_port = 6082 + +The :program:`nova-compute` service requires the following options to configure +SPICE console support. + +- :oslo.config:option:`spice.enabled` +- :oslo.config:option:`spice.agent_enabled` +- :oslo.config:option:`spice.html5proxy_base_url` +- :oslo.config:option:`spice.server_listen` +- :oslo.config:option:`spice.server_proxyclient_address` +- :oslo.config:option:`spice.keymap` + +For example, to configure this via a ``nova.conf`` file: + +.. code-block:: console + + [spice] + agent_enabled = False + enabled = True + html5proxy_base_url = http://IP_ADDRESS:6082/spice_auto.html + server_listen = 127.0.0.1 + server_proxyclient_address = 127.0.0.1 + keymap = en-us + +Replace ``IP_ADDRESS`` with the IP address from which the proxy is accessible +by the outside world. For example, this may be the management interface IP +address of the controller or the VIP. + + +Serial +------ + +Serial consoles provide an alternative to graphical consoles like VNC or SPICE. +They work a little differently to graphical consoles so an example is +beneficial. The example below uses these nodes: + +* controller node with IP ``192.168.50.100`` +* compute node 1 with IP ``192.168.50.104`` +* compute node 2 with IP ``192.168.50.105`` + +Here's the general flow of actions: + +.. figure:: figures/serial-console-flow.svg + :width: 100% + :alt: The serial console flow + +1. The user requests a serial console connection string for an instance + from the REST API. +2. The :program:`nova-api` service asks the :program:`nova-compute` service, + which manages that instance, to fulfill that request. +3. That connection string gets used by the user to connect to the + :program:`nova-serialproxy` service. +4. The :program:`nova-serialproxy` service then proxies the console interaction + to the port of the compute node where the instance is running. That port + gets forwarded by the hypervisor into the KVM guest. + +Configuration +~~~~~~~~~~~~~ + +To enable the serial console service, you must configure both the +:program:`nova-serialproxy` service and the :program:`nova-compute` service. +Most options are defined in the :oslo.config:group:`serial_console` group. + +The :program:`nova-serialproxy` service accepts the following options. + +- :oslo.config:option:`daemon` +- :oslo.config:option:`ssl_only` +- :oslo.config:option:`source_is_ipv6` +- :oslo.config:option:`cert` +- :oslo.config:option:`key` +- :oslo.config:option:`web` +- :oslo.config:option:`serial_console.serialproxy_host` +- :oslo.config:option:`serial_console.serialproxy_port` + +For example, to configure this via a ``nova-serialproxy.conf`` file: + +.. code-block:: console + + [serial_console] + serialproxy_host = 0.0.0.0 + serialproxy_port = 6083 + +The :program:`nova-compute` service requires the following options to configure +serial console support. + +- :oslo.config:option:`serial_console.enabled` +- :oslo.config:option:`serial_console.base_url` +- :oslo.config:option:`serial_console.proxyclient_address` +- :oslo.config:option:`serial_console.port_range` + +For example, to configure this via a ``nova.conf`` file: + +.. code-block:: console + + [serial_console] + enabled = True + base_url = ws://IP_ADDRESS:6083/ + proxyclient_address = 127.0.0.1 + port_range = 10000:20000 + +Replace ``IP_ADDRESS`` with the IP address from which the proxy is accessible +by the outside world. For example, this may be the management interface IP +address of the controller or the VIP. + +There are some things to keep in mind when configuring these options: + +* :oslo.config:option:`serial_console.serialproxy_host` is the address the + :program:`nova-serialproxy` service listens to for incoming connections. +* :oslo.config:option:`serial_console.serialproxy_port` must be the same value + as the port in the URI of :oslo.config:option:`serial_console.base_url`. +* The URL defined in :oslo.config:option:`serial_console.base_url` will form + part of the response the user will get when asking for a serial console + connection string. This means it needs to be an URL the user can connect to. +* :oslo.config:option:`serial_console.proxyclient_address` will be used by the + :program:`nova-serialproxy` service to determine where to connect to for + proxying the console interaction. + + +Frequently Asked Questions +-------------------------- - **Q: What is the difference between ``nova-xvpvncproxy`` and ``nova-novncproxy``?** A: ``nova-xvpvncproxy``, which ships with OpenStack Compute, is a proxy that - supports a simple Java client. nova-novncproxy uses noVNC to provide VNC + supports a simple Java client. ``nova-novncproxy`` uses noVNC to provide VNC support through a web browser. - **Q: I want VNC support in the OpenStack dashboard. What services do I @@ -467,50 +611,9 @@ Frequently asked questions about VNC access to virtual machines console connections, make sure that the value of ``novncproxy_base_url`` is set explicitly where the ``nova-novncproxy`` service is running. -Serial Console --------------- - -The *serial console* feature [1]_ in nova is an alternative for graphical -consoles like *VNC*, *SPICE*, *RDP*. The example below uses these nodes: - -* controller node with IP ``192.168.50.100`` -* compute node 1 with IP ``192.168.50.104`` -* compute node 2 with IP ``192.168.50.105`` - -Here's the general flow of actions: - -.. figure:: figures/serial-console-flow.svg - :width: 100% - :alt: The serial console flow - -1. The user requests a serial console connection string for an instance - from the REST API. -2. The `nova-api` service asks the `nova-compute` service, which manages - that instance, to fulfill that request. -3. That connection string gets used by the user to connect to the - `nova-serialproxy` service. -4. The `nova-serialproxy` service then proxies the console interaction - to the port of the compute node where the instance is running. That - port gets forwarded by the hypervisor into the KVM guest. - -The config options for those nodes, which are in the section -``[serial_console]`` of your ``nova.conf``, are not intuitive at first. -Keep these things in mind: - -* The ``serialproxy_host`` is the address the `nova-serialproxy` service - listens to for incoming connections (see step 3). -* The ``serialproxy_port`` value must be the very same as in the URI - of ``base_url``. -* The ``base_url`` on the compute node will be part of the response the user - will get when asking for a serial console connection string (see step 1 - from above). This means it needs to be an URL the user can connect to. -* The ``proxyclient_address`` on the compute node will be used by the - `nova-serialproxy` service to determine where to connect to for - proxying the console interaction. References ---------- -.. [1] https://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/serial-ports.html -.. [2] https://qemu.weilnetz.de/doc/qemu-doc.html#vnc_005fsec_005fcertificate_005fverify -.. [3] https://tools.ietf.org/html/rfc3280#section-4.2.1.10 +.. [1] https://qemu.weilnetz.de/doc/qemu-doc.html#vnc_005fsec_005fcertificate_005fverify +.. [2] https://tools.ietf.org/html/rfc3280#section-4.2.1.10