Symantec Access Management

Hi all,

I am working to set up two CA Directory DSA's for replication over SSL. I am having issues though it seems with the extensions and certificate purposes that my signing certificate authority places on the certificates. I am using openssl to generate the rsa key and csr instead of the dxcertgen tool because I wanted to add a full OU structure.

When I sign the certificate with my signing root ca I use

openssl ca -config /root/ca/intermediate/openssl.cnf -extensions server_cert -notext -md sha256 -in dsaname.csr -out dsaname.cer.pem

In that openssl.cf file the server_cert extension field looks like this:

[ server_cert ]

# Extensions for server certificates (`man x509v3_config`).

basicConstraints = CA:FALSE

nsCertType = server

nsComment = "OpenSSL Generated Server Certificate"

subjectKeyIdentifier = hash

authorityKeyIdentifier = keyid,issuer:always

keyUsage = critical, digitalSignature, keyEncipherment

extendedKeyUsage = serverAuth, clientAuth

I am using

dxcertgen -n ca.cer importca

to input the public key of the signing CA into my trusted.pem.  I then issue the command

dxcertgen report

and it verifies that my personalities/dsaname.pem and Trusted Root certificates in trusted.pem are all valid. I have already configured the dsa configuration files to allow ssl-auth and am able to login to JXPLORER via SSL forcing SSL + Username + Password.

The problem I am running into is doing replication from dsaA to dsaB. I have copied the knowledge .dxc files from dsaA to dsaB and vice versa. Created the replicationGroup.dxg file and sourced both of the .dxi files in that group file and then sourced them in there dsaname.dxi file.

An example of the trust flags I have set in the knowledge/dsaname.dxc file is

set dsa "smsessionstore20" =

{

    prefix        = <o smsession><ou sessionstore>

    dsa-name      = <o smsession><ou sessionstore><cn "smsessionstore20">

    dsa-password  = "secret"

    address       = tcp "editedforPosting" port 11400, tcp "editedforPosting" port 11443

    disp-psap     = DISP

    snmp-port     = 11400

    console-port  = 11401

    auth-levels   = clear-password, ssl-auth

    dsa-flags     = multi-write

    trust-flags   = allow-check-password, trust-conveyed-originator, trust-dsa-triggered-operations

    link-flags    = ssl-encryption, ssl-encryption-remote

};

When I start the dsa's to test the replication I am getting the following errors in the dsa_warn.log

[9] 20160223.162036.425 WARN : ssld_ssl_request failed

[7] 20160223.162043.440 WARN : TLS/SSL handshake failed for call from 172.16.113.150:53214

[2] 20160223.162059.410 WARN : ERROR IN HANDSHAKE

[2] 20160223.162059.410 WARN : 7f32c80008f8-   15030100 020230    ......0

[2] 20160223.162059.410 WARN : 2:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:s3_pkt.c:1300:SSL alert number 48

[2] 20160223.162059.410 WARN : ssld_ssl_request failed

[2] 20160223.162059.410 WARN : TLS/SSL handshake failed for call from 172.16.113.150:36521

[0] 20160223.162137.460 WARN : MW-DISP not in sync for 'smsessionstore20'

[0] 20160223.162137.460 WARN : Attempting to send update to peer 'smsessionstore20'

[6] 20160223.162137.465 WARN : Verify error 26: unsupported certificate purpose

[6] 20160223.162137.465 WARN : SSL Error

[6] 20160223.162137.465 WARN : 6:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1185:

The dsa_alarm.log states

] 20160223.160532.679 DSA_I1240 DSA shutting down

[0] 20160223.160824.757 DSA_W2650 Cannot get Multiwrite last update time for 'smsessionstore20'

[0] 20160223.160824.759 DSA_I1220 DSA started: dxserver 12.0.17 (build 11557) Linux 64-Bit

[0] 20160223.160824.759 DSA_I3200 License: dxserver 12.0.17 (build 11557) Linux 64-Bit prefix ou=sessionstore,o=smsession entry total 6

[0] 20160223.160824.759 DSA_I1150 DXgrid file usage: Filesize 500000000 Used bytes 1120 (1%) Reclaimable bytes 6

[9] 20160223.160925.819 DSA_E2735 Multiwrite-DISP: Unable to synchronize with peer 'smsessionstore20'

[6] 20160223.161733.263 DSA_E2735 Multiwrite-DISP: Unable to synchronize with peer 'smsessionstore20'

[2] 20160223.162743.798 DSA_E2735 Multiwrite-DISP: Unable to synchronize with peer 'smsessionstore20'

[6] 20160223.163753.376 DSA_E2735 Multiwrite-DISP: Unable to synchronize with peer 'smsessionstore20'

After doing some research I found something on Oracle's website about Directory replication over SSL stating

To Configure Replication Operations for SSL

This procedure shows example commands for setting up replication on a replication topology with two masters.

Note –

This example shows a simple replication configuration, using a self-signed certificate as generated during instance creation. When setting up replication over SSL in a production environment, you will have better security if you use Certificate Authority trusted certificates instead.

Replication over SSL will fail if the supplier server certificate is an SSL server-only certificate that cannot act as a client during an SSL handshake.

What server type extensions do my certificates need to be issued for to allow the dsa replication over SSL? server or client? When I set to client certificates I am unable to log in with JXPLORER.

Thank you for the help,

Adam Rusniak

I found this below in a previous post. Justin do you know what the -extensions flag needs to be set to in OpenSSL.cnf to allow for both server and client certificate usage ? Thank you.

Re: What type of cert(usage) is needed for CA Directory to use SSL?

Justin McDonald   Dec 9, 2015 2:16 AM (in response to Prakhar1)

As far as certificate usage goes the DSA personality certificate $DXHOME/config/ssld/personalities/{dsa_name}.pem requires for following:

Key Usages: DIGITAL_SIGNATURE, KEY_AGREEMENT, KEY_ENCIPHERMENT

Certificate Usages: SSL_CLIENT, SSL_SERVER

Notes

* The client certificate usage is required so that two DSAs can communicate with each other. In this case the the DSAs authenticate wit each other using certificate based authentication.

* The SubjectDN of the certificate for each DSA *must* but the same as the "dsa-name" field from the knowledge file for each DSA you are generating a certificate for, otherwise, DSAs will not be able to communicate.

* CA Directory ships with a certificate generation tool, running "dxcertgen certreq" will create a certificate signing request based on the DSA configuration. A certificate authority can then be used to generate and sign a certificate that can then be imported using "dxcertgen certmerge" where the certificate is merged with the private key created when the CSR was generated to for a personality PEM file

* The public certificate for the root CA (and intermediate certificates) should be added imported into $DXHOME/config/ssld/trusted.pem.

Hi Adam,

Can you double check the following:

Configuration (tlsv1 alert unknown ca)

HostA

$DXHOME/config/ssld/trusted.pem

$DXHOME/config/ssld/personalities/dsaA.pem

HostB

$DXHOME/config/ssld/trusted.pem                     <-- Same trusted.pem as HostA

$DXHOME/config/ssld/personalities/dsaB.pem  <-- signed by same root CA (trusted.pem) as dsaA.pem

Certificate Usage (unsupported certificate purpose)

I would recommend commenting out "nsCertType = server". The extendedKeyUsage is the correct method for specifying the intended usage of a personality certificate. Your current configuration for the EKU is correct.

Please let me know how you get on.

Cheers,

Justin

Justin,

Thank you very much! The trusted.pem were indeed the same the md5sum checked out.

You were spot on with removing nsCertType = server from the openssl.cnf file.

I removed all of the certificates and reissued new ones. This time I used dxcertgen -D smsessionstore2 -Z SHA256 -k 2048 certreq and then the certmerge after signature instead of using straight openSSL.

Here is the new snippet from the output of openssl x509 -in dsa.cer.pem -purpose

Certificate purposes:

SSL client : Yes

SSL client CA : No

SSL server : Yes

SSL server CA : No

Netscape SSL server : Yes

Netscape SSL server CA : No

S/MIME signing : No

S/MIME signing CA : No

S/MIME encryption : No

S/MIME encryption CA : No

CRL signing : No

CRL signing CA : No

Any Purpose : Yes

Any Purpose CA : Yes

OCSP helper : Yes

OCSP helper CA : No

Time Stamp signing : No

Time Stamp signing CA : No

and the extensions from the command openssl x509 -in dsa.cer.pem -noout -text

X509v3 extensions:

            X509v3 Basic Constraints:

                CA:FALSE

            X509v3 Subject Key Identifier:

                59:A9:DF:D2:A2:D1:07:D9:27:4A:7C:0F:98:D9:94:DD:0A:E2:BB:FE

            X509v3 Authority Key Identifier:

                keyid:33:59:62:C6:AB:2D:58:DC:69:8A:A1:E8:27:24:36:7A:BE:F2:FF:38

                DirName:/C=US/ST=edited/L=edited/O=editedforpost/OU=edited/CN=edited

                serial:10:00

            X509v3 Key Usage: critical

                Digital Signature, Non Repudiation, Key Encipherment, Key Agreement

            X509v3 Extended Key Usage:

                TLS Web Server Authentication, TLS Web Client Authentication

After I had the new personalities files created and booted up the DSA's , the Multwrite-DISP update applied successfully on both DSA's.

Last question - when I telnet into the dsa console and issue get dsp nothing is returned - is this what I should see?

Welcome to the DSA Management Console

dsa> get dsp

get dsp

--->

When I bring the dsaB offline and make a change on dsaA I do see this on the console when get dsp is issued and dsaB is brought online

dsa> get dsp

get dsp

---> ** ALARM **: DSA_I2830 Clearing multi-write queue: smsessionstore2

** ALARM **: DSA_I2690 Multiwrite-DISP: Peer 'smsessionstore2' updated

** ALARM **: DSA_I2695 Multiwrite-DISP: Update from 'smsessionstore2' applied

Here is a snippet from the alarm log showing the successful replication. I verified by adding some dummy data on dsaA and viewing the data replicating to dsaB with jxplorer. Justin I really appreciate the quick and accurate answer. Thank you!

3] 20160223.185125.375 DSA_I2695 Multiwrite-DISP: Update from 'smsessionstore2' applied

[5] 20160223.185125.384 DSA_I2830 Clearing multi-write queue: smsessionstore2

[6] 20160223.185125.384 DSA_I2690 Multiwrite-DISP: Peer 'smsessionstore2' updated

That's good news!! Thanks for the feed back.

For DXconsole (and the configuration), every command requires a trailing semicolon.

Please try "get dsp;".

Thanks Justin. I guess my eyes were playing tricks on me and I was missing the semi-colon. All is well now!

Appreciate everything,

Adam

I have same issue, however when I have a look at my openssl.cnf file, I find that nsCertType is already commented out.

But I also get the same issue. Could you please guide me, what all needs to be checked