XCA  <author>Christian Hohnstädt, <tt/christian@hohnstaedt.de/  <date>0.6.0 28/01/2007 <abstract>  <nidx>(your index root)</nidx>  This application is intended for creating and managing X.509 certificates, certificate requests, RSA and DSA private keys and CRLs. Everything that is needed for a CA is implemented. All CAs can sign sub-CAs recursively. These certificate chains are shown clearly. For an easy company-wide use there are customiseable templates that can be used for certificate or request generation. All crypto data is stored in a local and portable file format. </abstract>  <toc>  <sect>Introduction This application is intended as Certificate- and key-store and as signing application issuing certificates. All data structures (Keys, Certificate signing requests, Certificates and Templates) can be imported and exported in several formats like DER or PEM. Import means reading a file from the filesystem and storing the data structure into the database file, while exporting means to write the data structure from the database file to the filesystem to be e.g imported into an other application. When opening a new database the first time, it needs a password to encrypt the private keys in the database. This is the default password. Every time this database is opened the application asks for the password. This input dialog may be canceled and the database is still opened successfully. However, the access to the keys is not possible without supplying the correct database password everytime a key is used. The different cryptographic parts are divided over 5 Tabs: Keys, Requests, Certificates, Templates and Revocation lists. All items can be manipulated either by a context menu available by right-clicking on the item, or by using the buttons at the right border. Every item is identified by an internal name which is unique in one tab-view and is always shown in the first column. <sect1>File formats There are several default file-formats to exchange cryptographic data with other applications. <itemize> <item><bf>DER</bf> <bf>D</bf>istinguished <bf>E</bf>ncoding <bf>R</bf>ules is the binary ASN.1 encoding of the data. <item><bf>PEM</bf> <bf>P</bf>rivacy-<bf>E</bf>nhanced <bf>M</bf>ail is the base64 encoded version of the <bf>DER</bf> formated data with additional header and footer lines to be transported via e.g. E-mail <item><bf>PKCS#X</bf> <bf>P</bf>ublic <bf>K</bf>ey <bf>C</bf>ryptography <bf>S</bf>tandards published by <url url="http://www.rsasecurity.com" name="RSA Laboratories"> </itemize> <sect1>Further reading <label id="otherdoc"> <enum> <item><url url="http://tldp.org/HOWTO/SSL-Certificates-HOWTO/" name="SSL Certificates HOWTO"> <item><url url="http://ospkibook.sourceforge.net/" name="OS-PKI book"> </enum> <sect1>Copyright <tscreen><verb> /* * Copyright (C) 2002 - 2006 Christian Hohnstaedt. * * All rights reserved. * * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are met: * * - Redistributions of source code must retain the above copyright notice, * this list of conditions and the following disclaimer. * - Redistributions in binary form must reproduce the above copyright notice, * this list of conditions and the following disclaimer in the documentation * and/or other materials provided with the distribution. * - Neither the name of the author nor the names of its contributors may be * used to endorse or promote products derived from this software without * specific prior written permission. * * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * * * This program links to software with different licenses from: * * http://www.openssl.org which includes cryptographic software * written by Eric Young (eay@cryptsoft.com)" * * http://www.trolltech.com * * * * http://www.hohnstaedt.de/xca * email: christian@hohnstaedt.de * */ </verb></tscreen> <sect1>Credits <tscreen><verb> Kerstin Steinhauff <tine (at) kerstine.de> Arts and graphics Ilya Kozhevnikov <ilya (at) ef.unn.ru> Registry stuff for WIN32 Paul Kirner <kirner (at) fhwgt.de> Providing compile and test hardware Wolfgang Glas <wolfgang.glas (at) ev-i.at> Implementation of SPKAC and UTF8 support Bugreports and feature input: Frank Werner <Frank (at) WeSoft.de> Peter Bieringer <pb (at) bieringer.de> </verb></tscreen> Thank you very much.  <sect>Updating from older versions Older versions of XCA used a Berkely database for storing the crypto items. Starting from version 0.6.0 this has changed to a simple endian independent file format for several reasons: <itemize> <item>The Berkeley db API was a moving target and every distribution had different versions installed. Handling all versions well ended up in an "#ifdef hell" where every second build failure was based on a different API in an other db version. <item>The database got corrupted if a log.0000001 file was deleted. <item>copying a database from one place to another was only possible, if the log file was also copied. This breaks the approach of having one single, simpe file containing the crypto items. </itemize> Since XCA 0.6.0 is not compiled with Berkeley DB support it cannot read old file formats. The extension of files has changed from *.db to *.xdb . Importing old databases is done by the following steps: <itemize> <item>Use db_dump of your distribution to dump the database to an ASCII file. (Windows users will find a db_dump.exe in the XCA installation dir). The command is: db_dump -f xca.db.dump xca.db <item>Start XCA and open a new database (e.g. xca.xdb). XCA asks for a password for this new, empty database. <item>Point your mouse to "File->Import old db_dump" and select the file "xca.db.dump" <item>XCA now asks for the password of the ORIGINAL database, since the ASCII dump still contains the private keys encrypted with the password. <item>Enjoy XCA 0.6.0 </itemize>  <sect>Download The most recent version of XCA can be downloaded from <url url="http://sourceforge.net/projects/xca" name="XCA download">  <sect>Command line options Usage: <tt>xca [dbname.xdb] <options></tt> Next to the usual X command line options. There are the following <itemize> <item>-v show version information and exit <item>-k expect all following non-option arguments to be RSA keys <item>-r expect all following non-option arguments to be Certificate signing requests or SPKAC requests <item>-c expect all following non-option arguments to be Certificates <item>-p expect all following non-option arguments to be PKCS#12 files <item>-7 expect all following non-option arguments to be PKCS#7 files <item>-l expect all following non-option arguments to be Revocation lists <item>-t expect all following non-option arguments to be Xca templates <item>-P expect all following non-option arguments to be a PEM formated file <item>-d set the database filename <item>-x Exit after processing all command line options </itemize> when invoked with one of the -k -r -c -p -7 -l -t options, the application will show the details of the items and import them into the database if desired. If the application should exit afterwards, just supply the -x option. This behaviour enables xca to be used as default application for viewing PKI items.  <sect>Common actions Many actions are common to all crypto parts and are mentioned here once for all. The goal of this application is to provide an easy to use signing-tool and also a common place for all selected PKI items like Requests or Certificates. <sect1>Importing items The import of an item can be done by either clicking the import button on the right or via the context menu available by right clicking into the list. The import function is smart enough to probe all known formats independent of the file extension: <itemize> <item><tt>Keys:</tt> PEM private key, PEM public key, DER private key, DER public key, PKCS#8 private key. <item><tt>Requests</tt> DER request, PEM request, Netscape SPKAC request. <item><tt>Certificates</tt> DER certificate, PEM certificate (PKCS#12 and PKCS#7 certificates must be imported with an extra button, because they can contain more than one certificate and key) </itemize> After selecting the filename XCA will probe for the known formats of that item and in case of an error it prompts the <tt>last</tt> OpenSSL error message. It is possible to select more than one file by selecting them with SHIFT click. Also the <tt>Import</tt> menu may be used to load items. Next to the filetypes above, it also supports <tt>PEM</tt> import. PEM describes the encoding instead of the filetype. So a PEM file can be any type of private key, crl certificate or csr. This import facility discovers the type and loads it. When importing more than one Key, CRL, Certificate or Request all items are shown in a Multi-import dialog. When importing a PKCS#7 or PKCS#12 item, the contained Keys and Certificates are shown in the Multi-import dialog. By using the Multi-import dialog the items can be examined, imported or dropped. After reading the item it searches for this item in the database and if it is unique, the item is stored in the database. Otherwise it shows a message containing the internal name of this item in the database. <sect1>Details of an item The details dialog can be accessed by double clicking the item, by the context menu or by the button on the right. The names of the issuers certificate and the corresponding key are clickable and their content will be shown on "double-click" <sect1>Renaming an item An Item can be renamed via the context menu by right-clicking on the item, by pressing <F2> or by the Rename button on the right border. If the new name of the item already exists in the database a <tt>_01</tt> will be appended to keep the internal name unique. <sect1>Deleting Items Items can be deleted by the button on the right or via the context menu. If a certificate signed by this application is going to be removed the application will warn you once more, because you can not revoke a deleted certificate. Thus only delete a certificate signed by you if you never exported it. Certificate signing requests can be deleted when they get signed, because they are not needed anymore. The request can be recovered from the resulting certificate by exporting the certificate to a request. This is however only possible if you own the private key of the certificate. Multiple items may be selected to delete them all at once.  <sect>The Certificate input dialog<label id="wizard"> This input dialog is the central part for collecting all data regarding Certificates, Requests and Templates. It will be invoked whenever such an item is going to be created or, in case of a Template, is altered. <sect1>Source This page is not shown when creating or changing templates. <sect2>Signing request If it is desired to either enroll a certificat from a PKCS#10 request by a CA, or to create a certificate from a request by self-signing it, the request can be selected here. In the later case the private key of the request must be available. <sect2>Signing Either self-signing or the CA certificate for signing may be selected here. Additionally, the desired signing algorithm can be adjusted. The drop-down list contains all <ref id="ca_cert" name="CA certificates"> with an available private key. <sect2>Signature algorithm Usually SHA256 or higher should be used, but since older windows versions including XP can not handle them, Windows users should consider using SHA1. <sect2>Templates The fields of the certificate can be preset by the values of a template by selecting it and clicking Apply. <sect1>Personal settings <sect2>Distinguished Name On this Page all personal data like country, name and email address can be filled in. Only the <tt>Internal name</tt> is mandatory. The <tt>Country code</tt> field must either be empty or exactly contain two letters representing your country code; e.g. <tt>DE</tt> for Germany. If you want to create an SSL-server certificate the <tt>Common name</tt> must contain the <tt>DNS</tt> name of the server. Other rarely used <tt>name-entries</tt> can be selected in the dialog below. Only items that were added using the Add button are recognized. All items can be added more than once, even those from above. This is not very usual but allowed. <sect2>Private Key Keys can be generated here <tt>on the fly</tt> by pressing the button. The newly generated key will be stored in the database and stay there, even if the input dialog is canceled. The drop-down list of the keys only contains keys that were not used by any other certificates or requests. The key-list is not available for creating or changing templates. This tab does not appear when signing a request, because the request contains all needed data from this tab. <sect1>X509v3 Extensions The next 3 tabs contain all fields for adjusting the certificate extensions. It is not in the focus of this document to explain them all in detail. The most important are the <tt>Basic Constraints</tt> and the <tt>Validity</tt> range. For more information consult the documents in <ref id="otherdoc">. If you don't know what this is all about please read those documents before creating any certificates. <sect2>Basic Constraints If the type is set to <tt>Certification Authority</tt>, the certificate is recognized by XCA and other instances as issuer for other certificates. Server-certificates or E-Mail certificates should set this extension to <tt>End entity</tt> (strongly recommended) or disable it completely by setting it to <tt>Not defined</tt> <sect2>Validity Range The <tt>not Before</tt> field is set to the current date and time of the operating system and the <tt>not After</tt> field is set to the current date and time plus the specified time range. For templates the specified times are not saved, because it does not make much sense. Rather the time range is stored and automatically applied when selecting this template. Applying the time range means to set notBefore to "now" and notAfter to "now + time range". If the <tt>midnight</tt> button is set both dates will be rounded down and up to midnight.  <sect>Asymetric keys <label id="keys"> For asynchronous encryption and signing keys are needed. All keys are stored encrypted in the database using the 3DES algorithm. All keys carry a use counter which counts the times it is used. For new requests or certificates the list of available keys is reduced to the keys with a use counter of 0. <sect1>Generating Keys The dialog asks for the internal name of the key and the keysize in bits. Even if the drop-down list only shows the most usual values, any other value may be set here by editing this box. While searching for random prime numbers a progress bar is shown in the bottom of the base application. After the key generation is done the key will be stored in the database. <sect1>Key export Keys can be exported by either selecting the key and pressing Export or by using the context-menu. This opens a Dialogbox where the following settings can be adjusted: <itemize> <item>filename <item>Output format ( DER, PEM ) <item>Public or Private Key <item>PKCS#8 format <item>Encryption of the exported file (yes/no) </itemize> The filename is the internal name plus a <tt>pem</tt>, <tt>der</tt> or <tt>pk8</tt> suffix. When changing the fileformat, the suffix of the filename changes accordingly Only PKCS#8 or PEM files can be encrypted, because the DER format (although it could be encrypted) does not support a way to supply the encryption algorithm like e.g. <tt>DES</tt>. Of course, encryption does not make sense if the private part is not exported.  <sect>Certificate Signing Requests <label id="csr"> Certificate signing requests are described in PKCS#10 standard. They are used to supply a Certification Authority with the needed information to issue a valid certificate for you, without knowing your private key. This includes your personal information, your public key and additional extensions. Netscape SPKAC files can not be created or exported, but they can be imported and signed. This requests are marked in the Signature field as SPKAC and a Netscape icon is shown. <sect1>Generating a new Request After clicking on the <tt>New Request</tt> button the Certificate dialog will be started to ask all needed information for generating a new Request. See: <ref id="wizard" name="The Certificate input dialog"> The request generation can also be invoked by the context menu of a certificate (Export->Request). This menu point is only available if the private key of the certificate is available. In this case all needed data is copied from the certificate and the Wizard is not invoked. <sect1>Request export Requests can be exported by the context-menu or by the button on the right. The filename and type can be selected in the next dialog. <sect1>Request details All information contained in the request are shown. If the keystore contains the private key corresponding to the request the keys internal name is shown in the <tt>Key</tt> field.  <sect>Certificates All certificates from the database are displayed in a tree view reflecting the chain dependencies. If there is a CA certificate and several client certificates signed by this CA, the client certificates can be shown by clicking on the plus sign of the CA certificate. <sect1>CA certificates <label id="ca_cert"> XCA recognizes CA certificates if the CA flag in the <tt>Basic Constraints</tt> is set to true. If there is a corresponding private key, the <tt>CA</tt> submenu in the context-menu is enabled. For building the chains the CA flag is disregarded, because there are some CAs without this flag. Instead it consideres the issuer name and the signature to decide which certificate is the issuer. <sect1>Generating certificates After clicking on the <tt>New Certificate</tt> button the Certificate input dialog will be started to ask all needed information for generating a new Certificate. See: <ref id="wizard" name="The Certificate input dialog"> Certificate creation can also be invoked by the context menu of the certificate list background or by the context menu of the request. In this case the Wizard is preset with the Request to be signed. If a <tt>CA certificate</tt> is selected in the certificate list, this certificate is preselected as signer certificate. <sect1>Certificate details The signer is the internal name of the issuers certificate, SELF SIGNED if it is self signed or SIGNER UNKNOWN if the issuer's certificate is not available. The validity is set to valid if the certificate's dates are valid or to Not valid if they are not, regarding to the internal time and date of the OS. If the certificate is revoked, the revocation date will be shown instead. On the Subject and Issuer tab the distinguished name is also displayd in a format define in RFC2253 for copy&paste. <sect1>Certificate trust The certificate trust can be changed by the context menu of the certificate. It can be set to: <itemize> <item><bf>Not trusted</bf> - never trust this certificate, even if we trust the issuer. This is the default for imported self-signed certificates. <item><bf>Trust depends on issuer</bf> - only trust this certificate, if we trust the issuer. This is the default for imported and generated non-self-signed certificates. <item><bf>Always trust</bf> - always trust this certificate, even if we do not trust the issuer's certificate or if it is absent. This is the default for generated self-signed certificates. </itemize> <sect1>Certificate export The filename can be selected in the export dialog and the Export format: <itemize> <item><bf>PEM</bf> - PEM encoded <item><bf>PEM with Certificate chain</bf> - PEM encoded certificate and all issuers up to the root certificate in one file <item><bf>PEM all trusted Certificates</bf> - List of all PEM encoded certificates that are marked als Always trusted (usually all self-signed certificates) in one file for e.g. apache as trusted cert store. <item><bf>PEM all Certificates</bf> - All PEM encoded certificates in one file. <item><bf>DER</bf> - DER encoded certificate. <item><bf>PKCS#7</bf> - DER encoded PKCS#7 structure containing the certificate. <item><bf>PKCS#7 with Certificate chain</bf> - DER encoded PKCS#7 structure containing the certificate and all issuers up to the root certificate. <item><bf>PKCS#7 all trusted Certificates</bf> - DER encoded PKCS#7 structure containing all certificates that are marked als Always trusted <item><bf>PKCS#7 all Certificates</bf> - DER encoded PKCS#7 structure containing all certificates. <item><bf>PKCS#12</bf> - PKCS#12 structure containing the certificate and the corresponding private key <item><bf>PKCS#12</bf> - PKCS#12 structure containing the certificate, the corresponding private key and the chain of all issuers certificates. <item><bf>PEM cert + key</bf> - concatenation of the private key and certificate in a format used by apache or the X509 patch for OpenSSH. <item><bf>PEM cert + PKCS8 key</bf> - concatenation of the private key in PKCS#8 format and certificate. </itemize> When exporting PKCS#12 structures you are asked later for an encryption password. <sect1>Certificate revocation Certificates can only be revoked, if the private key of the issuer's certificate is available. The certificate will marked as revoked and the revocation date will be stored with the certificate. <sect1>Certificate renewal Certificates can only be renewed, if the private key of the issuer's certificate is available. Renewal is done by creating a new certificate as a copy of the original one with adjusted validity dates. <sect1>CA special functions The context menu of CA certificates contains the CA submenu. that makes the following functions available: <itemize> <item><bf>Serial</bf> The serial number of the next certificate signed by this issuer. <item><bf>CRL days</bf> The days until the next CRL release. <item><bf>Signing Template</bf> The default template for signing certificates. <item><bf>Generate CRL</bf> Generate the CRL by collecting all revoked certificates and their revocation date. </itemize> <sect>Certificate Revocation Lists All certificates are issued for a restricted timeperiod of validity. However it can happen that a certificate shoud not be used / becomes invalid before the "not after" time in the certificate is reached. In this case the issuing CA should revoke this certificate by putting it on the list of revoked certificates, signing and publishing it. <sect1>Generation of Certificate revocation lists In XCA this can be done by the context-menu of the CA and the "revoke" entry in the context-menu of the issued certificate. First all invalid certificates are marked as revoked and then a Certificate Revocation List should be created and will be stored in the database.  <sect>Object IDs Private Object IDs and OID lists for the distinguished name or extended key usage can be added in files listed below. The files are: <itemize> <item><bf>oids.txt</bf> addidtional Object IDs <item><bf>eku.txt</bf> Content of <tt>ExtendedKeyUsage</tt> <item><bf>dn.txt</bf> Content of <tt>DistinguishedName</tt> <item><bf>aia.txt</bf> Content of <tt>AuthorityInformationAccess</tt> </itemize> The search path for all the files is listed below. <bf>Unix</bf> <itemize> <item>PREFIX/share/xca/ <newline>PREFIX is usually /usr or /usr/local <item>/etc/xca/ <item>$HOME/xca/ </itemize> <bf>Windows</bf> <itemize> <item>Installation directory <newline>e.g.: C:\Programs\xca </itemize> All Object IDs that are not official, but belong to your company or organisation can be added in the file <tt>oids.txt</tt>. All possible locations for this file are searched and all <tt>oids.txt</tt> files found are loaded. This way the application-installer adds some in /usr/share/xca, the Administrator in /etc/xca and the user in $HOME/xca. The format of this file is:<newline> <bf>OID</bf>:<bf>shortname</bf>:<bf>longname</bf><newline> Leading and trailing spaces between the colons and the text are ignored. Lines starting with a <bf>#</bf> are ignored. The files containing OID lists (<tt>eku.txt, dn.txt, aia.txt</tt>) are handled in a different way, only the first one found is used. The format of this files is one entry per line. The entry can be either the numerical OID like <tt>1.3.6.1.5.5.8.2.2</tt>, the short name like <tt>iKEIntermediate</tt> or the long name <tt>IP security end entity</tt>. Lines starting with a <bf>#</bf> are ignored. If this files shall contain new inofficial OIDs, they must be also mentioned in one of the <tt>oids.txt</tt> files.  <sect>Appendix Here one can find several examples for file formats: <sect1>PEM <tscreen><verb> -----BEGIN CERTIFICATE----- MIIC0zCCAjygAwIBAgIQKNOqLomUfJxugwU5FHGCSjANBgkqhkiG9w0BAQQFADBf MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT LkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw HhcNOTcxMDEzMDAwMDAwWhcNMDQwMTA1MjM1OTU5WjBDMREwDwYDVQQKEwhWZXJp U2lnbjEuMCwGA1UECxMlVmVyaVNpZ24gQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVh bCBDQTCBnTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEA3CqZnW4z/LtBdsQ5Ho33 dueQD3RVYWFyPPg3SxsfCOkwHXDFFolgM0ZIf8bQmj12mMOhwaxS0Re5FARphlxh T7NlZYtjou4hfEGvrXJAw02Rs0m+mPtXx1ousEun7wkk84GdOMWS2kqnmFGp2DB2 LWrWry9+2xEqhftlYFpF6BsCAQOjga0wgaowDwYDVR0TBAgwBgEB/wIBADBEBgNV HSAEPTA7MDkGC2CGSAGG+EUBBwEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52 ZXJpc2lnbi5jb20vcGNhMi5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQE AwIBBjANBgkqhkiG9w0BAQQFAAOBgQCeTebTWFTbJFzaxCsD3432QbAsiAng0VcA OzlDYn1BMIRT0NsrJbeTjQ8cOmvCkgesEPYsm+SniOktibXDJT+n87Can4+0CQBx qUUsBUoG0PtMGjH4Vr/QD5sG8cMecG3FJR4CWwKitoz47h7sxM50B6RB9je1eIvS 1NMPRGO1nQ== -----END CERTIFICATE----- </verb></tscreen> <sect1>SPKAC <tscreen><verb> SPKAC=MIIBPzCBqTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAw9eRsqOS9k gd5Wk5Z2OWLCB8TuYlhRKpvfdIh6dZBERIQ/7xojDhOeg235Y/iWR0Jj9pXLOz2Q dL7ppUwsGCnXXQGCdTG4OXAziBZTcLoMIxHzIvJ9pgX3APsuEWospGJzDPQv0sup GCEiQK6qzAFa5BISQpIczHufBFGtLbGesCAwEAARYFaGVsbG8wDQYJKoZIhvcNAQ EEBQADgYEAZOCMay68W5629GI/fj0R7AGJBQBCu79KtAxcnmiDhI4ELWIoB04wJg GqlcdCY6eo1CHZN9LNVltzSUghVl/zPwaBFodhI6CbSnMfk+nkPa2psXQXoQs2+1 7QPXfOlqDvqyOhwGFnPDMYSLeYVwQjh/Miov+vPV5+8Qhc2owuh9A= CN=Fred vom Jupiter O=Jupiter Gas Ltd. OU=CRM inner planets L=Jupiter </verb></tscreen> </article>