[empty image] [empty image]
[empty image]
[empty image] [empty image] [empty image]
[empty image]

secure shell with
X.509 v3 certificate support



12 Feb 2018 : Version x509-11.2
What's new:
  • X.509 name compare error
    Authorized keys or know host files may contain record (line) with X.509 certificate details (distinguished name or X.509 certificate blob, aka. public key). In such case if key (client or host) is a X.509 key, equality checks compare items of certificate distinguished name. Unfortunately in PKIX-SSH 9.1 one of ports to OpenSSL 1.1.0* introduce critical error in X.509 name compare method - if both items are from PrintableString type they are considered equal. Error does not exist if other types are compared.
    Work-around is authorized keys or know hosts to contain only plain public key blob. Thus compare will use public key part of X.509 certificate.
    Thanks to Nicolas Fournil and Emmanuel Deloget for report.
  • use of hostname after free
    For use in session key renegotiation process host name is stored into a global variable!!! PKIX-SSH 8.9 has a number of memory leak fixes. One of fixes frees allocated copy of host-name created in method ssh_login. Issue is that one of called methods store value to a global variable for later user in rekeying.
    Work-around around is do not use option RekeyLimit.
    Thanks to Lukas Kuster for report.
  • build with libressl
    PKIX-SSH 11.0 start to use macro DEFINE_STACK_OF from OpenSSL 1.1.0* API. Program code provides fail-back solution for builds with earlier versions. LibreSSL pretend to be compatible with OpenSSL but fail to announce properly compatibility version. As result fail-back solution was not activated and build fail. Detection of DEFINE_STACK_OF is rewritten to allows build with various LibreSSL versions.
  • key load crash if crypto is libressl 2.6*
    For performance reasons PKIX-SSH uses BIO_new_mem_buf - BIO interfaces with read only memory buffer that avoid extra allocation of memory. Due to mix of issues - insufficient libressl linkage options and broken function implementation inherited from OpenSSH (openbsd "compat"-library) PKIX-SSH commands crash on key load.
    Now broken function in corrected in PKIX-SSH code but application is not immune to similar failures in the future even with earlier version of libressl.
  • libressl 2.6* failure with DSA/ECDSA signature
    At configure time PKIX-SSH warns if build is with libressl 2.6*. Also commands raise warning at run-time if are linked with libressl 2.6*.
    Work-around is to use earlier versions. If this is not possible please disable all key algorithms that use dsa and ecdsa signature, otherwise application may crash.
  • legacy RSA/DSA code clean up
    PKIX-SSH 7.1 (15 Jan 2012) was first release that support FIPS enabled OpenSSL library. Support requires rsa/dsa code for plain-keys to use modern "EVP"-API. FIPS support remain outdated OpenSSH code for rsa/dsa sign and verify operations was still available under "C"-preprocessor conditions.
    So more the five years later outdated code, inherited from OpenSSH, is removed from PKIX-SSH code base.
  • legacy PKCS#11 code clean up
    Code inherited from OpenSSH is removed - it does not work well with secure tokens that has X.509 certificate. Also it has limited functionality - only RSA keys.
    Note that PKIX-SSH code supports RSA and EC keys and work well with secure tokens as those devices usually store X.509 certificate and public key is optional.

19 Dec 2017 : Version x509-11.1
What's new:
  • Protected authentication path for EC-keys
    Use of RSA keys stored on a secure token supports protected authentication path (pinpad reader). Unfortunately functionality was not implemented for EC-keys. With refactoring PKCS#11 login functionality protected authentication path is available for EC-keys as well.
  • print public key for externally stored identities
    Now ssh-keygen command option -y, that print an public key to stdout, accepts keyfile name in enhanced identity format.
    Remark: PKIX-SSH could use externally stored identities - for mode details see description of IdentityFile in manual page ssh_config(5). In brief if identity name start with "engine:" instead from file identity load is redirected to "loadable cryptographic module" (engine). Prefix "store:" could be used if cryptographic library supports ossl_store(7) functionality (upcoming OpenSSL functionality).
  • build fixes
    Build system is modernized to use more recent scripts. Also duplicate dependency objects or libraries are removed.

8 Oct 2017 : Version x509-11.0
What's new:
  • Extension server-sig-algs
    As finally agreed in "draft-ietf-curdle-ssh-ext-info" extension lists public-key algorithm names instead signature names.
    No impact on deployed installations as PKIX-SSH prefer own extension publickey-algorithms@roumenpetrov.info that lists by design public-key algorithm. Other ssh implementation that support extensions does not support RFC 6187 keys. As result for them list of signature algorithms is same as list of public-key algorithm.
  • prefer RFC 6187 key format
    For connection to remove host client first tries X.509 algorithms. Now algorithm in RFC 6187 format will take precedence of legacy format, if server send algorithm extension. With other words order of algorithms in option X509KeyAlgorithm has no more effect. In practice PKIX-SSH 11.0+ clients (in default configuration) will prefer RFC 6187 format in connections to PKIX-SSH 10.1+ hosts.
    Note that to use an X.509 algorithm in has to be allowed by configuration (option PubkeyAlgorithms) and listed in algorithm extension offered by server.
  • multi-algorithm host-keys
    Now daemon (server) for each hostkey offers all public key algorithms and could use any of offered algorithms in ssh protocol. For instance RSA host key with X.509 certificate could be used in following public-key algorithms: "x509v3-sign-rsa", "x509v3-ssh-rsa", "ssh-rsa", "rsa-sha2-256" or "rsa-sha2-512".
    Host key notification is updated as well.
  • OpenSSL Store-API
    Upcomming OpenSSL version 1.1.1 supports store retrieval functions - ref. manual page ossl_store(7). The store functionality allows applications to retrieve keys, X.509 certificates and etc. using universal interface (API).
    PKIX-SSH engine related code is refactored and updated to load identities using store-API. In such case identify name should starts with "store:" followed by URI of scheme supported by openssl store. For instance with "e_nss" openssl loadable module (engine) you use identity named either "engine:[friendly name]" for custom interface or "store:[nss_uri]" for store interface where "[nss_uri]" is in format "nss:[friendly name]".
    Note store result could be tested with command openssl storeutl .... [nss_uri].
  • Remove ssh v1
    Complete remove of code that supports legacy ssh protocol verision 1. Modification includes removal of configure option --enable-ssh1 as well.
  • Program version for ssh-keyscan
    Announce PKIX-SSH version in keyscan to be used in compatibility detection.
  • X.509 key fingerprint
    Until now fingerprint (hash) of X.509 keys was computed over certificate that match private key.
    Key material (user identity or host key) could be used in various public-key algorithms, with or without X.509 cetificate. For instance lets identity with X.509 RSA certificate is used as x509v3-sign-rsa in session to host 1 and as ssh-rsa in connection to host 2. In such case key fingerprint will be different depending of session in spite of fact that private key is one and the same.
    To avoid ambiguities code is updated to calculate fingerprint only over common part - public key. Modification may impact some programs that monitor log files.
  • X.509 code refactoring
    X.509 related code is updated and refactored to use library like functions.
  • Management of X.509 keys for agent
    Agent code is improved to use newly functions that better detect X.509 keys. Now agent and its key management utility (ssh-add) use by default user and system ca-store in all cases. This is useful for keys in RFC 6187 format where key format contain list of extra certificates used to build chain. Utility ssh-add accepts multiple arguments for options -S as specified options argument could be either file or directory (new). Argument is similar to client options CACertificateFile and CACertificatePath and is used as additional locations to search for certificate when is build chain for keys in RFC 6187 format.
  • Manual pages
    Precise content of identity or host-keys files - file may contain extra certificates not only for ECDSA but for RSA and DSA keys as well.
    Do not mention "protocol version 2" as legacy version 1 is not supported at all.

21 May 2017 : Version x509-10.2
What's new:
  • android port
    Improve support for virtual user account, relocatable location of configuration, relax directory permissions and ignore login records.
  • skipped identities
    Add extra messages to debug reasons for skipping an identity (not allowed by configuration or not accepted by peer, if server announce supported algorithms in extension)
  • skipped identities
    Add extra messages to debug reasons for skipping an identity (not allowed by configuration or not accepted by peer, if server announce supported algorithms in extension)
  • work with broken "server-sig-algs" extension
    Server extension "server-sig-algs" was not implemented properly in OpenSSH 7.3 and 7.4. New version detect broken servers and replaces incorrect algorithm announcement with correct list.
    For instance OpenSSH 7.3 list only algorithms rsa-sha2-256 and rsa-sha2-512. As result PKIX-SSH functionality for "adaptive public key algorithm selection" in connection to OpenSSH 7.3 skips all other identities except those with RSA key.
  • [RFC6187] keys
    Now certificates sent for a identity encoded in [RFC6187] are used in verification process. This mean that there is no requirement client or server to keep intermediate certificates in X.509 store for [RFC6187] keys.

31 Mar 2017 : Version x509-10.1.1
What's new:
  • portability
    Functions "llabs" is not defined as library function in Android API before level 21 (v5.0, LOLLIPOP). It is replaced with local version to ensure binary compatibility with oldest API.
  • compatibility
    Some OpenSSL compatible libraries hide and do not export OpenSSL functions like UTF8_getc and UTF8_putc. To avoid build issue a local version is bundled. Note that this piece of code is under OpenSSL license. Also code is fixed to avoid implicit function declarations warnings.
  • FIPS in identification string
    If secsh daemon runs in FIPS mode it will send string "FIPS" in comment field of protocol identification string when the connection is established.

25 Mar 2017 : Version x509-10.1
What's new:
  • server extension "publickey-algorithms@roumenpetrov.info"
    Added experimental support for extension negotiation mechanism - client offer support of extension negotiation and server respond with list of supported public key algorithms within a custom extension "publickey-algorithms@roumenpetrov.info".
    This experimental functionality is basis for future PKIX-SSH versions to prefer [RFC6187] algorithms instead legacy one like x509v3-sign-rsa and x509v3-sign-dss.
  • extension "server-sig-algs"
    This extension is considered as limited variant of extension above, i.e. server supports only public key algorithms for which name of algorithm match name of signature. Note this is not the case for [RFC6187] algorithms. For compatibility reasons PKIX-SSH server offers "server-sig-algs" extension as well.
  • new server options AcceptedAlgorithms
    This pattern like global only option allows server to limit algorithms listed in extension "publickey-algorithms@roumenpetrov.info". By default all supported public key algorithms are announced.
    Note that this options adds additional restriction to options PubkeyAlgorithms and HostbasedAlgorithms that could be set conditionally per user and etc - see option Match.
    Indirectly option limit list send in "server-sig-algs" extension.
  • new RSA key algorithms
    This version supports new public key algorithms: rsa-sha2-256 (default) and rsa-sha2-512. Client and agent will use them only if server announce them in one of extensions mentioned above.
  • adaptive public key algorithm selection
    This is experimental technology based on server extension mentioned above. Adaptive selection is used in public authentication to the servers that announce supported public-key algorithms. Client with try to find match between those algorithms and announced by server taking into account client option PubkeyAlgorithms as well.
    For instance let an identity is a X.509 RSA certificate. Such identity could be used in "x509v3-sign-rsa", "x509v3-ssh-rsa", "rsa-sha2-256" and "rsa-sha2-512" or "ssh-rsa" public key algorithms. Let client option PubkeyAlgorithms is default one - '*'. Let server announce "ssh-rsa" then this algorithm will be used in public key authentication nevertheless where identity is stored - file system, or secure token (pkcs#11 module), or provided by ssh agent, or openssl loadable module (engine).
    Note if server does not send extensions you could set manually PubkeyAlgorithms per host to achieve similar functionality.
  • hostkey update and rotation
    Ensure working update and rotation of hostkeys in [RFC6187] formats. Feature could be requested by client with option UpdateHostKeys.
  • additional compatibility for [RFC6187]
    Added detection for other ssh products that implement EC [RFC6187] keys similar as PKIX-SSH before to be implemented properly in 10.0.
  • log launch in FIPS
    Now server write message that program is run FIPS mode on standard error instead system log. Client, agent and key generator output such message as well. On system with fipscheck, in addition to server and client, verification is added to agent and key generator programs.
    Note that you should move checksum files for system server(sshd) and client(ssh) from fipscheck directory ( /usr/lib{64,}/fipscheck) to directory of executable to allow PKIX-SSH and system secure shell to coexist.
  • OpenSSL versions
    No restrictions for OpenSSL version. PKIX-SSH supports builds with most recent (1.1.+, current) and ancient (0.9.7*) versions of OpenSSL cryptographic library build in different configurations like FIPS or Kerberos enabled.
  • prolong UsePrivilegeSeparation options
    Use of server options UsePrivilegeSeparation is useful in environments where server runs in user space.

25 Feb 2017 : Version x509-10.0
What's new:
  • true x509v3-ecdsa-sha2-* algorithms
    Versions before 10.0 incorrectly implement [RFC6187] - public key-blob does not include algorithm name and ecdsa signature blob is in ASN.1 opaque format.
    New release implement correctly EC X.509 public-key algorithms and supports backward compatibility with previous releases.
  • x509v3-ssh-*algorithms
    Support x509v3-ssh-rsa and x509v3-ssh-dss algorithms ([RFC6187]) in addition to x509v3-sign-rsa and x509v3-sign-dss.
    Note x509v3-sign-* are still preferred.
  • demon advertise PKIX-SSH release
    Secure shell sever advertise PKIX-SSH release version in connections and logs. Version number could be used to detect capabilities of secure shell server.
  • support VPN tunnel for Darwin's utun device
  • code cleanup
    Completely remove possibility to build without X.509 store.
    Rewrite many methods to use new library style API and mainly to take into account public-key algorithm name and compatibilities.

19 Dec 2016 : Version x509-9.3
What's new:
  • EC token keys for OpenSSL 1.1+
    PKCS#11 module was not fully ported to OpenSSL API v1.1. Forgotten method is now implement.
    Note new options related to pkcs#11 module - whitelist path pattern, for instance ssh-agent option -P.
  • Protocol 1 keys for SSH server
    PKIX-SSH still support SSH1 server keys. They will be removed in major release (10.0).
  • Android port
    Work-around for getsid syscall wrapper, missing in some versions of bionic C-library.

18 Sep 2016 : Version x509-9.2
What's new:
  • crash after processing X.509 certificate subject in known hosts file
    One code optimisation OpenSSH code adds pointer to end of key set when processing keys in regular "blob" format (key pub-file). Key part optionally is followed by key comment. X.509 certificate subject format is specific and is processed separately. Key comment is not applicable in that case and end pointer left unassigned. At some point client code try to clear leading spaces from end pointer (comment) and in case of X.509 subject reads from uninitialised memory.
    PKIX-SSH version 8.8, 8.9, 9.0 and 9.1 are impacted. Work-around is to use temporary "blob" format for X.509 keys.
    Crash is not triggered always. For instance it is somehow in build with high level of optimization(gcc -Q2).
  • host-based authentication and RFC 6187
    Helper program for host-based authentication (ssh-keysign) is updated to support system default X.509 store. As result ecdsa key server host key with X.509 certificates may contain optionally extra certificates.
  • document internal build of certificate chain
    Update manual details use of extra certificates used in internal build of certificate chain implemented in version 9.0.
  • precise support of libcrypto features
    Support properly some ancient OpenSSL version - without sha-256. As result PKIX-SSH works with wide range of OpenSSL version - from 0.9.7 to 1.1.

26 Aug 2016 : Version x509-9.1
What's new:
  • Updates in supported OpenSSL API versions
    OpenSSL 1.1.0 is published on 25 Aug 2016. Unfortunately in last few weeks API is changed again. PKIX-SSH version 9.1 is updated to release version of OpenSSL 1.1 API.
    Until now PKIX-SSH still support OpenSSL 0.9.6 API, although build raise error if detect OpenSSL version before 0.9.7. Finally specific PKIX-SSH workaround for OpenSSL 0.9.6 is removed from code.
  • recent autotool configuration
    Update to recent version detection (config.guess) and validation (config.sub) scripts. Configure script is generated with autoconf 2.69.
  • ECDSA algorithms in documentation
    Manual pages and readme first list ECDSA, then for RSA and DSA X.509 public key algorithms. Documentation order match how code list public key algorithms in order of precedence.
  • do not generate missing rsa1 keys
    Default startup script will not generate missing rsa1 keys if support for SSH1 is not enabled.

3 Aug 2016 : Version x509-9.0
What's new:
  • internal build of certificate chain
    Public key algorithms described in [RFC6187] require a chain of certificates leading to a trusted certificate authority to be sent as part of public key data.
    Before version 9.0 it was user responsibility to specify those certificates as part of private key file. It was not possible for keys and X.509 certificates stored in external devices to satisfy [RFC6187] requirement. Now when a [RFC6187] key is loaded programs (client, server) use certificates from private file and X.509 store to build the chain.
    PKCS11 module is a specific case. It is case when module is used with agent (ssh-add -s ..). Now ssh agent support certificate X.509 and use system default store defined at build time. In addition new ssh-add option -S allows user to add extra certificates to store. Those certificates and system default are used to build certificate chain.
  • remove build option --disable-x509store
    Support of [RFC6187] public key algorithms require working X.509 store.
  • remove build option --enable-x509v3-ecdsa
    Support of x509v3-ecdsa-sha2-... now is default for X509KeyAlgorithm option. With other words support for X.509 certificates with EC is considered complete.
  • port to OpenSSL 1.1 API
    Most of code is rewritten to use API from OpenSSL 1.1 development branch.
    The new API is back-ported locally and used if build is with OpenSSL versions before 1.1. The model for functional checks at configure time allows build with OpenSSL compatible libraries.
  • Android port
    Code is updated to support various versions of Bionic "C" libraries.
    Now specific to Android logging functionality is used from all executable.
    A simplified password file is managed. It supports only one password record with md5 hash. This allows ssh daemon to support password authentication.
  • dump of configuration
    Command that dump client/server configurations now properly generate directive VAType.

2 Aug 2016 : Version x509-9.0
New major release in progress...

Features (valid for latest version) :

  • public key algorithms:
    • x509v3-ecdsa-sha2-nistp256
    • x509v3-ecdsa-sha2-nistp384
    • x509v3-ecdsa-sha2-nistp521
    • x509v3-sign-rsa
    • x509v3-sign-dss
    • x509v3-ssh-rsa
    • x509v3-sssh-dss
    ECDSA, RSA or DSA X.509 certificates could be used as "user identity" and/or "host key" in SSH "Public Key" and "Host-Based" authentications.
    • different "x509v3-sign-rsa" signatures
      As support for SHA-1 and MD5 signature format PKIX-SSH is interoperable with implementations from multiple vendors. Both formats are supported because "SSH Transport Layer Protocol" internet drafts does not specify signature format in case of X.509 certificate for RSA key.
    • different packing of "x509v3-sign-dss" signature
      PKIX-SSH is interoperable with implementations from multiple vendors. It support DSA signatures packed in format as is described in [RFC2459] and "dss_signature_blob" format as is specified in "SecSH Transport" draft and [RFC4253].
      Note "SSH Transport Layer Protocol" internet draft before version 12 specify "x509v3-sign-dss" public key algorithm to use signature format as is described in [RFC2459], i.e. r and s packed in ASN.1 SEQUENCE. Some vendors pack DSA signature values in "dss_signature_blob" as is specified in "SecSH transport" draft for "ssh-dss" signature.
    • use key and certificate stored in "external devices"
      Implementation requires working OpenSSL engine. The identity used in client authentication could refer to external key and/or certificate in format engine:[ENGINE_NAME]:[CERT_CRITERIA], where [ENGINE_NAME] is name of OpenSSL engine and [CERT_CRITERIA] is specific to engine search criteria to find the key and certicate.
      For instance you could use "friendly name" to access key and certificate stored in "Network Security Services (NSS)" database with e_nss engine from http://roumenpetrov.info/e_nss/. NSS s used in programs(web-browser. e-mail client) like Firefox, SeaMonkey, Thunderbird.
    • "PKCS#11"module
      As second option PKIX-SSH could use PKCS#11 shared library(module) to communicate with EC or RSA X.509 certificates and private key provided by PKCS#11 tokens.
  • verification (default feature)
    By default server(sshd) and clients(ssh,scp,sftp) always verify signatures and validity of certificates in chain when a X.509 certificate is used in authentication. When verification fail that certificate is disallowed. Certificate verification can be disabled when PKIX-SSH is build without "X.509 store" support. Ofr instance at configure script is run with --disable-x509store option. In additional client is able to verify remote key using DNS with CERT RR (resource record).
  • validation
    • CRL (default feature)
      When a X.509 certificate is used in authentication, server and client always verify signatures and validity of existing CRLs issued by authorities in certificate chain. Certificate is allowed only when no one of certificates in the chain is revoked. Validation is disabled only when PKIX-SSH is build without "X.509 store" feature.
    • OCSP (default feature)
      Additional validation is performed when PKIX-SSH is configured to use OCSP and a X.509 certificate is used in authentication.
    ssh can verify host identification using CERT Resource Record published in DNS.
  • PKIX-SSH Agent (ssh-agent and ssh-add programs)
    Authentication agent can hold X.509 certificates.
  • ssh-keyscan
    This tools can gather in addition following X.509 host keys:
    • x509v3-ecdsa-sha2-nistp256
    • x509v3-ecdsa-sha2-nistp384
    • x509v3-ecdsa-sha2-nistp521
    • x509v3-ssh-rsa
    • x509v3-ssh-dss
    • x509v3-sign-rsa
    • x509v3-sign-dss
  • ssh-keysign
    This tools used in "Host-Based Authentication" can sign "host keys" containing X.509 certificate (ECDSA, RSA or DSA).
  • ssh-keygen
    when user identity contain a X.509 certificate, command:
    • creates public key and proposed "SECSH Public Key File Format" for that certificate.
    • shows fingerprint of certificate.
    • prints CERT RR (resource record) for specified hostname.
  • regression tests
  • manual pages
  • README.x509v3
    Brief description of server and client configuration, regression tests, troubleshooting and FAQ.

Get your version from download pages.


  • to implement wildcards(patterns) for DN in "authorized keys" and "known hosts" files;
  • to extend "time limits" with specified time for given revoked certificates.


  1. Initial
    Initial support began from 4 Apr 2002 with version "a". Version "b" issued on 11 Jun 2002 add "X509 store". The store is in use in verification process when a certificate is used as user's identity is ssh session. The store allow use of "distinguished name" in authorized keys file.
  2. Second stage
    In this phase certificate support is implemented in other PKIX-SSH executables. For first ssh-keygen support certificates since version "c" (20 Jun 2002). This version introduce regression tests. Later in version "d" (30 Jul 2002) support is added to ssh agent.
    As result PKIX-SSH support certificates as user identity entirely.
  3. Complete support
    Since version "e" (21 Nov 2002) manual pages are updated with information about X.509 certificate support. As well support for certificates as host key in introduced. As version "f" (30 Jan 2003) CRL are supported. Because certificate support is complete as version "f" client prefer algorithms with certificates for host key.
  4. Compatibility
    Compatibility phase begin with version "g" (3 Feb 2003). In version "g1" (30 Apr 2003) regression test scripts are updated to work well with various shells. Since version "g2" (12 Jun 2003) public key algorithm "x509v3-sign-rsa" accept "sha1" signatures in addition to "md5" and now PKIX-SSH is interoperable with all major ssh implementations. This version work fine with OpenSSL 0.9.7+. Later in versions "g3" (25 Feb 2004) and "g4" (9 Maj 2004) code, documentation and regression test are cleaned up.
  5. Validator
    Fifth phase began with OCSP (Online Certificate Status Protocol) support added in version "h" (6 Apr 2004). Later version schema is changed to more common format with numbers N.N{.N} and next version is 5.1. In version 5.3 compatibility is enhanced to support (in addition to [RFC3279] DSA signatures) format defined for "ssh-dss" signature. Self issued certificates can be pertimed by "autorized keys" file since version 5.4 if configuration allow this. Correction for OCSP responder location obtained from certificate is added in version 5.4 and OCSP SSL support is enabled in 5.5.
  6. International
    Since version 6.0 (7 Aug 2007) PKIX-SSH can deal with "distinguished name" stored in autorized keys file as UTF-8 string or escaped. Before to compare printable attributes are converted to utf-8.
  7. Integration
    Starting from version 7.0 (22 Aug 2011) PKIX-SSH can communicate with other applications by using OpenSSL engines. For instance client could use certificates and keys stored in external devices.
    Version 7.1 (15 Jan. 2012) support build with FIPS enabled OpenSSL library and adds direct support of X.509 certificates(RSA) from PKCS11 module. Since this version sha1 is preferred algorithm and programs start to identify as PKIX in comment from ssh identification string.
    Build for android host is supported since version 7.2 (22 Apr. 2012). With version 7.5(19 May 2013) "known hosts" file may contain distinguished name of host X.509 certificate.
  8. Elliptic
    Version 8.0 (11 Aug.2014) is first secure shell implementation that support X.509 ECDSA algorithm as defined in [RFC6187] - initialy for client and server. With version 8.2 (23 Nov. 2014) adds support of X.509 ECDSA algorithm in agent. From version 8.4 (1 Jul 2015) EC keys or X.509 certificates stored on external device could be used with loadable cryptographic modules - OpenSSL engines.
    Support for FIPS environments is enhanced in version 8.1 (29 Sep. 2014) with fipscheck for "Red Hat" FIPS validated environment. Version 8.2 (23 Nov. 2014) is succesfully tested with Solaris 11.2 FIPS validated OpenSSL module.
    Lists with allowed algorithms support patterns since version 8.3 (18 Mart 2015).
    Support for EC keys and certificates stored in PKCS#11 tokens is added in version 8.8 (29 Feb 2016).

News archives:


Recommendet OpenSSL library versions:
Before to use X.509 certificates please read OpenSSL security advisories:
OpenSSL library versions:

[empty image]
[empty image] [empty image] Last modified : Sunday February 11, 2018 [empty image]