openstack
/
nova
Code Issues Proposed changes

Merge "doc: Rewrite the console doc"

This commit is contained in:
Zuul 2018-11-19 04:34:02 +00:00 committed by Gerrit Code Review
parent fd540e2135 0e801a9e62
commit 238184b23c
1 changed files with 346 additions and 243 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

589
doc/source/admin/remote-console-access.rst
View File

@ -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 <section_configuring-compute-migrations>`,
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
<https://github.com/novnc/noVNC/commit/99feba6ba8fee5b3a2b2dc99dc25e9179c560d31>`_.
.. _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
~~~~~~~~~~~~~
<graphics type="vnc" autoport="yes" keymap="en-us" listen="0.0.0.0"/>
.. 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