Re: OpenSSL compilation errors in Windows

[Nagalakshmi V J]

Hi Matt,

Kindly provide your inputs for the below mail.

Thanks & Regards,
Nagalakshmi V J

From: Nagalakshmi V J 
Sent: 22 October 2019 10:41:40
To: Matt Caswell ; openssl-users@openssl.org 

Cc: Nagalakshmi V J 
Subject: RE: OpenSSL compilation errors in Windows


Hi Matt,



Could you please help to get any clue on the ACCESSOR APIs of the following.



I tried searching APIs. Not getting exact matches. Referred the below links.



https://www.openssl.org/docs/man1.1.1/man3/SSL_set_info_callback.html

https://www.openssl.org/docs/man1.1.1/man3/EVP_md5.html



Getting similar error for the below code.



tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf),

 pGenerator->master_secret,sizeof(pGenerator->master_secret),

 km,tmp,num);



Struct ssl_ctx_st {

…

const EVP_MD *md5;  /* For SSLv3/TLSv1 'ssl3-md5' */

const EVP_MD *sha1; /* For SSLv3/TLSv1 'ssl3->sha1' */

…

}



struct evp_md_st {

int type;

int pkey_type;

int md_size;

unsigned long flags;

int (*init) (EVP_MD_CTX *ctx);

int (*update) (EVP_MD_CTX *ctx, const void *data, size_t count);

int (*final) (EVP_MD_CTX *ctx, unsigned char *md);

int (*copy) (EVP_MD_CTX *to, const EVP_MD_CTX *from);

int (*cleanup) (EVP_MD_CTX *ctx);

int block_size;

int ctx_size;   /* how big does the ctx->md_data need to be */

/* control function */

int (*md_ctrl) (EVP_MD_CTX *ctx, int cmd, int p1, void *p2);

} /* EVP_MD */ ;





Thanks and regards,

Nagalakshmi



From: Nagalakshmi V J 
Sent: Tuesday, October 22, 2019 9:39 AM
To: Matt Caswell ; Nagalakshmi V J 
; openssl-users@openssl.org
Subject: Re: OpenSSL compilation errors in Windows



Hi Matt,

Yes. Exactly we followed the same and able to resolve errors. Thank you so much 
for the support and guidance. I'll get back if any further errors.

Thanks & Regards,
Nagalakshmi V J



From: Matt Caswell mailto:m...@openssl.org>>
Sent: 21 October 2019 21:26:32
To: Nagalakshmi V J 
mailto:nagalakshm...@altran.com>>; 
openssl-users@openssl.org 
mailto:openssl-users@openssl.org>>
Subject: Re: OpenSSL compilation errors in Windows



** This mail has been sent from an external source **


On 20/10/2019 08:43, Nagalakshmi V J wrote:
> Hi Matt,
>
> This link is having few APIS. But for getting master_key_length, I don't
> find any API. Not sure if we need to use getMasterKey API for that.

You can use SSL_SESSION_get_master_key() for this.

Note this comment in the RETURN VALUES section:

"For the other functions, if outlen is greater than 0 then these
functions return the number of bytes actually copied, which will be less
than or equal to outlen. If outlen is 0 then these functions return the
maximum number of bytes they would copy -- that is, the length of the
underlying field."

So to discover the master_key_length call the function with outlen to
zero. You can then allocate an appropriate sized buffer and call the
function again in order to get the actual master key.

Matt


>
> I will try to use these APIs and get back.
>
> Thanks & Regards,
> Nagalakshmi V J
> 
> *From:* Matt Caswell mailto:m...@openssl.org>>
> *Sent:* 18 October 2019 14:48:33
> *To:* Nagalakshmi V J 
> mailto:nagalakshm...@altran.com>>;
> openssl-users@openssl.org 
> mailto:openssl-users@openssl.org>>
> *Subject:* Re: OpenSSL compilation errors in Windows
>
> ** This mail has been sent from an external source **
>
>
> On 18/10/2019 11:49, Nagalakshmi V J wrote:
>> Now the issue is SSL_session structure is also having accessor APIs
>> which I am not aware of. So I need to get the APIs for accessing the
>> master_key_length,etc.. given in the above code. Those are not listed
>> in the openssl link referred.
>
> On this page look a the various functions beginning with "SSL_SESSION_"
> in the name:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.1.1_man3_&d=DwICaQ&c=cxWN2QSDopt5SklNfbjIjg&r=zbjUR56YPF3jaTRTjX4KZlHM9-LmYAuR5atSqEGOnpA&m=MZhYFrTAuuHOqAirPiGbT1CY6HDdH2U_CWYq12626Ts&s=gE0JHTVoToRHQRu5h2amvKa5WzyXsortlw0IoQd3VG4&e=
>
> From the code sample you gave you are probably mostly interested in the
> functions on this page:
>
> https://urldefense.

Re: openssl 1.0.2 with TLS 1.2

[Anne M. Hammond]

Thanks Rich.

openssl version -a

…

OPENSSLDIR: "/usr/local/openssl-1.0.2a/ssl"

—
That tells me the dir openssl is looking in.

ls /usr/local/openssl-1.0.2a/ssl

total 36
drwxr-xr-x 6 root root  4096 2019-10-23 16:34 .
drwxr-xr-x 7 root root  4096 2019-10-22 12:27 ..
drwxr-xr-x 2 root root  4096 2019-10-22 13:23 certs
drwxr-xr-x 6 root root  4096 2019-10-21 16:01 man
drwxr-xr-x 2 root root  4096 2019-10-21 16:02 misc
-rw-r--r-- 1 root root 10835 2019-10-21 16:02 openssl.cnf
drwx-- 2 root root  4096 2019-10-21 16:29 private

ca-bundle.crt IS in certs.

On another system, where openssl s_client works, there is a link:

lrwxrwxrwx   1 root root19 May 10  2015 cert.pem -> certs/ca-bundle.crt

I created this link in /usr/local/openssl-1.0.2a/ssl and now 
openssl s_client works on the system I am working on.

I will update to the newer version.  

Thank you for the pointer.

Re: PSK with TLSv1.3

[Matt Caswell]

On 23/10/2019 12:32, Johannes Bauer wrote:
> One step further... I've peeked at s_server.c and copied some of that
> code. I.e., concretely I now am at:
> 
> const unsigned char tls13_aes128gcmsha256_id[] = { 0x13, 0x01 };
> const SSL_CIPHER *cipher = SSL_CIPHER_find(ssl, tls13_aes128gcmsha256_id);
> if (!cipher) {
>   return 0;
> }
> SSL_SESSION_set_cipher(sess, cipher);
> 
> But, uhm... this is positively terrifying code. Is this how it's
> supposed to look, i.e., hard-coded magic numbers in the application?! Or
> is that just the route s_server took and there's a preferred, better way?

Unfortunately the only way we have for getting hold of a single
SSL_CIPHER object is to use the SSL_CIPHER_find() function. You can also
get the list of ciphers configured for a particular SSL object or
SSL_CTXbut you that's an even worse way of getting hold of a single
SSL_CIPHER. It would be nice to have a function to get hold of an
SSL_CIPHER based on its name and a function to get hold of one based on
its id as defined in the tls1.h, e.g. TLS1_3_CK_AES_256_GCM_SHA384 - but
at the moment such a function doesn't exist.


> 
> In any case, while it throws a different error message now, it still
> does not work:
> 
> PSK server SSL 0x6230fd00 identity foo len 3 sess (nil)
> 140710464452352:error:14201076:SSL routines:tls_choose_sigalg:no
> suitable signature algorithm:../ssl/t1_lib.c:2649:
> 
> I've never in the setup limited the signature algorithms and s_client
> does not, either (when I peek at the ClientHello it advertises a whole
> bunch of signature algorithms).

Since you're using PSKs I'm guessing you haven't set up a certificate.
If no suitable PSK has been found then OpenSSL will press ahead and
attempt to do an "initial" handshake with a certificate. It gets so far
and attempts to find a signature algorithm to use that is in the list of
signature algorithms presented by the client, as well as in the list of
signature algorithms configured for the server, and *also* is suitable
for use with one of the certificates configured for use by the server.
If there are no certificates configured then there is no signature
algorithm that can match these criteria, and you will get this error
message.

Matt

Re: PSK with TLSv1.3

[Matt Caswell]

On 23/10/2019 10:24, Johannes Bauer wrote:
> Hi list,
> 
> I'm in the process of refactoring/updating code that has been using
> TLS-PSK with TLSv1.2 for a number of years successfully. I want to
> upgrade it so that it uses TLSv1.3 exclusively.
> 
> I find it *exceptionally* hard to wrap my head around the new API and
> the documentation/manpages are extremely confusing to me.

I'd be grateful if you could submit suggested improvements as PRs to
make this clearer for the next person who comes along trying to do this.


> 
> E.g., while
> https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_psk_use_session_callback.html
> mentions specifically TLSv1.3 clients, there's no mention of server
> implementation

The page you referenced is the man page for clients. The man page for
servers is here:

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_psk_find_session_callback.html

Unfortunately this page is not made any clearer by a copy & paste error
in the opening paragraph which suggests it is about the client side API
calls rather than the server side one. I've just opened a PR to fix that
here:

https://github.com/openssl/openssl/pull/10245


> and the text does not seem to have been updated for
> TLSv1.3 entirely (e.g., there's mention of "the callback" -- clearly
> previously there was only one, now there's two,
> SSL_psk_use_session_cb_func and SSL_psk_client_cb_func).
> 
> I'm struggling with all of it, in particular the way the server callback
> works in TLSv1.3: What I'm doing now is register a
> 
> static int psk_server_callback(SSL *ssl, const unsigned char *identity,
> size_t identity_len, SSL_SESSION **sessptr);
> 
> using
> 
> SSL_CTX_set_psk_find_session_callback(cctx, psk_server_callback);
> 
> Then, inside the callback I create a SSL_SESSION* in the callback (if I
> want to return a PSK) using SSL_SESSION_new(). Setting the master key
> (that's the PSK, right?) using SSL_SESSION_set1_master_key and the
> protocol version using SSL_SESSION_set_protocol_version is straightforward.
> 
> But what the heck am I supposed to do with SSL_SESSION_set_cipher? The
> text in
> https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_psk_find_session_callback.html
> does not contain any hint on what to do in the server case and the text
> provided in the client manpage is exceedingly confusing:
> 
> "Only the handshake digest associated with the ciphersuite is relevant
> for the PSK (the server may go on to negotiate any ciphersuite which is
> compatible with the digest). The application can use any TLSv1.3
> ciphersuite."
> 
> So, wait, I can use any TLSv1.3 ciphersuite but it's not relevant
> because only the MD of the suite is used, everything else is discarded?
> So I return a cipher suite value, but it doesn't have to do anything
> with the cipher suites that I allow, it's just a "wrapper" for a MD?

Yes, exactly that. This comes about because of some quirks in the
TLSv1.3 spec. Historically (TLSv1.2 and below) the ciphersuite that is
negotiated is an important part of the session (SSL_SESSION object) and
the same ciphersuite is used in any subsequent resumption of that
session. In TLSv1.3 there is no difference between a PSK and a session.
The mechanism used for establishing a connection using a PSK is exactly
the same one used for resuming a session. So when we establish an
initial connection in TLSv1.3 we store away various values in the
session in exactly the same way that we do for TLSv1.2, and then use
some of them in the resumption. In the case of the ciphersuite its
actually only the MD part that we're interested in. With a PSK of course
there was no "initial handshake", so there was no previous ciphersuite
negotiated. However, since the mechanism is the same as for a resumption
we still need to have one there so we can get the MD out of it - which
leads to this slightly surprising way of doing things.


> 
> Here's what I'm doing right now in my server callback:
> 
> static int psk_server_callback(SSL *ssl, const unsigned char *identity,
> size_t identity_len, SSL_SESSION **sessptr) {
>   fprintf(stderr, "PSK server SSL %p identity %s len %ld sess %p\n", ssl,
> identity, identity_len, *sessptr);
>   SSL_SESSION *sess = SSL_SESSION_new();
>   SSL_SESSION_set1_master_key(sess, (const unsigned char*)"\x00\x11\x22", 
> 3);
>   SSL_SESSION_set_cipher(sess, SSL_get_pending_cipher(ssl));
>   SSL_SESSION_set_protocol_version(sess, TLS1_3_VERSION);
>   *sessptr = sess;
>   return 1;
> }
> 
> All error checking omitted for now, this is obviously just a sample.
> When I try to connect to my server on the command line using s_client:
> 
> $ openssl s_client -connect 127.0.0.1:12345 -psk_identity foo -psk 001122
> 
> The server pukes:
> 
> PSK server SSL 0x62300100 identity foo len 3 sess (nil)
> 139933268309760:error:141F906E:SSL routines:tls_parse_ctos_psk:bad
> extension:../ssl/statem/extensions_srvr.c:1267:

That error is coming from this sanity check:

if (P

Re: Preferred way of passing user context void* inside SSL*

[Viktor Dukhovni]

On Wed, Oct 23, 2019 at 01:21:54PM +, Salz, Rich via openssl-users wrote:

> >Is there a way for me to piggyback a void* inside the SSL structure so
> that I can access it from within the callback?
>   
> Yes, you can use SSL_set_app_data and SSL_get_app_data which are documented
> in https://github.com/openssl/openssl/pull/10216 (and due to be merged to
> master soon)

If the data is needed by a *library* and not "the application",
then it is not appropriate to use index 0, which is reserved for
"the application".  In that case, the library needs to register its
own "ex data index".  Examples can be seen at:

1-time init:  
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L353
Setter usage: 
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L977
Getter usage: 
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L255

-- 
Viktor.

RE: openssl and external card reader support in TLS

[Michael Wojcik]

> From: tobias.w...@t-systems.com [mailto:tobias.w...@t-systems.com]
> Sent: Wednesday, October 23, 2019 02:11
>
> Our PKCS11 module development will discontinue and therefore I can`t use it
> anymore, but the idea is great and very interesting.
> To give more details we need a callback or similar mechanism to replace the
> signature created in Certificate TLS message with our signature coming from
> the card reader.

For OpenSSL 1, the Engine mechanism is the way to do this. If you're 
discontinuing your PKCS#11 interface, then I think the only option is to write 
a custom engine.

For OpenSSL 3, I understand there's a new Provider mechanism for this purpose, 
but I haven't investigated it.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

Using X509_verify_cert with (possibly) OCSP?

[Bruce Stephens]

Suppose I want to verify a certificate, and I've collected some CRLs
and some OCSP responses. How can I do that?
If I just want to verify revocation for the end certificate (so
X509_V_FLAG_CRL_CHECK rather than X509_V_FLAG_CRL_CHECK_ALL) then
that's straightforward: I use X509_verify_cert without those settings
and then do the OCSP check for the end certificate.
But how can I check the whole chain, using some mixture of CRLs and OCSP?
It looks like I can use verify_cb and perform my own checks when the
error is X509_V_ERR_UNABLE_TO_GET_CRL.
I think really what I'd want is to have some more low-level callback
used in check_cert or check_revocation, but I don't see one.
In 1.0.2 I'm just changing check_revocation (since ) but in order to
keep the usual CRL checking that involved basically copying check_cert
and a bunch of related functions with small changes to one or two of
them (because they're mostly static so I can't just call them). In
OpenSSL-1.1 that doesn't look so attractive (and it's not terribly
pretty with 1.0.2) because the code accesses things in X509 and
X509_CRL that aren't accessible.
Am I missing something obvious? Does the TLS code do this in some way?
(It doesn't look like it does, but possibly I'm just missing it.)

Re: Preferred way of passing user context void* inside SSL*

[Johannes Bauer]

On 23.10.19 15:21, Salz, Rich wrote:
>>Is there a way for me to piggyback a void* inside the SSL structure so
> that I can access it from within the callback?
>
> Yes, you can use SSL_set_app_data and SSL_get_app_data which are documented 
> in https://github.com/openssl/openssl/pull/10216 (and due to be merged to 
> master soon)

Ah, completely overlooked that!

Thanks, Rich, this scratches *exactly* my itch.

All the best,
Joe

Re: Preferred way of passing user context void* inside SSL*

[Salz, Rich via openssl-users]

>Is there a way for me to piggyback a void* inside the SSL structure so
that I can access it from within the callback?
  
Yes, you can use SSL_set_app_data and SSL_get_app_data which are documented in 
https://github.com/openssl/openssl/pull/10216 (and due to be merged to master 
soon)

Preferred way of passing user context void* inside SSL*

[Johannes Bauer]

Hi list,

yet another question. In my process with TLS13-PSK, I've noticed that
the PSK callback does not have a user-definable callback context value.
However, the callback is passed the SSL* which I created when the
session was established.

Is there a way for me to piggyback a void* inside the SSL structure so
that I can access it from within the callback?

I've noticed a couple of member variables that might be abused for this
purpose (async_cb_arg, allow_early_data_cb_data,
default_passwd_callback_userdata, msg_callback_arg) and think in my
usecase they hopefully should all be safe to use (I don't use async I/O,
no early data, no SRP, no msg callback) -- but is this the preferred way
to do it? I.e., hijack a different callback argument that isn't used?

Am I overlooking the supposed way of doing this? Or is this typically
done via global variables (which in my case I *really* would want to avoid)?

Cheers,
Johannes

Re: PSK with TLSv1.3

[Johannes Bauer]

On 23.10.19 11:24, Johannes Bauer wrote:

> All error checking omitted for now, this is obviously just a sample.
> When I try to connect to my server on the command line using s_client:
>
> $ openssl s_client -connect 127.0.0.1:12345 -psk_identity foo -psk 001122
>
> The server pukes:
>
> PSK server SSL 0x62300100 identity foo len 3 sess (nil)
> 139933268309760:error:141F906E:SSL routines:tls_parse_ctos_psk:bad
> extension:../ssl/statem/extensions_srvr.c:1267:
>
> And I have no idea what that's supposed to mean.

One step further... I've peeked at s_server.c and copied some of that
code. I.e., concretely I now am at:

const unsigned char tls13_aes128gcmsha256_id[] = { 0x13, 0x01 };
const SSL_CIPHER *cipher = SSL_CIPHER_find(ssl, tls13_aes128gcmsha256_id);
if (!cipher) {
return 0;
}
SSL_SESSION_set_cipher(sess, cipher);

But, uhm... this is positively terrifying code. Is this how it's
supposed to look, i.e., hard-coded magic numbers in the application?! Or
is that just the route s_server took and there's a preferred, better way?

In any case, while it throws a different error message now, it still
does not work:

PSK server SSL 0x6230fd00 identity foo len 3 sess (nil)
140710464452352:error:14201076:SSL routines:tls_choose_sigalg:no
suitable signature algorithm:../ssl/t1_lib.c:2649:

I've never in the setup limited the signature algorithms and s_client
does not, either (when I peek at the ClientHello it advertises a whole
bunch of signature algorithms).

Any advice?
Thank you,
Johannes

PSK with TLSv1.3

[Johannes Bauer]

Hi list,

I'm in the process of refactoring/updating code that has been using
TLS-PSK with TLSv1.2 for a number of years successfully. I want to
upgrade it so that it uses TLSv1.3 exclusively.

I find it *exceptionally* hard to wrap my head around the new API and
the documentation/manpages are extremely confusing to me.

E.g., while
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_psk_use_session_callback.html
mentions specifically TLSv1.3 clients, there's no mention of server
implementation and the text does not seem to have been updated for
TLSv1.3 entirely (e.g., there's mention of "the callback" -- clearly
previously there was only one, now there's two,
SSL_psk_use_session_cb_func and SSL_psk_client_cb_func).

I'm struggling with all of it, in particular the way the server callback
works in TLSv1.3: What I'm doing now is register a

static int psk_server_callback(SSL *ssl, const unsigned char *identity,
size_t identity_len, SSL_SESSION **sessptr);

using

SSL_CTX_set_psk_find_session_callback(cctx, psk_server_callback);

Then, inside the callback I create a SSL_SESSION* in the callback (if I
want to return a PSK) using SSL_SESSION_new(). Setting the master key
(that's the PSK, right?) using SSL_SESSION_set1_master_key and the
protocol version using SSL_SESSION_set_protocol_version is straightforward.

But what the heck am I supposed to do with SSL_SESSION_set_cipher? The
text in
https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_psk_find_session_callback.html
does not contain any hint on what to do in the server case and the text
provided in the client manpage is exceedingly confusing:

"Only the handshake digest associated with the ciphersuite is relevant
for the PSK (the server may go on to negotiate any ciphersuite which is
compatible with the digest). The application can use any TLSv1.3
ciphersuite."

So, wait, I can use any TLSv1.3 ciphersuite but it's not relevant
because only the MD of the suite is used, everything else is discarded?
So I return a cipher suite value, but it doesn't have to do anything
with the cipher suites that I allow, it's just a "wrapper" for a MD?

Here's what I'm doing right now in my server callback:

static int psk_server_callback(SSL *ssl, const unsigned char *identity,
size_t identity_len, SSL_SESSION **sessptr) {
fprintf(stderr, "PSK server SSL %p identity %s len %ld sess %p\n", ssl,
identity, identity_len, *sessptr);
SSL_SESSION *sess = SSL_SESSION_new();
SSL_SESSION_set1_master_key(sess, (const unsigned char*)"\x00\x11\x22", 
3);
SSL_SESSION_set_cipher(sess, SSL_get_pending_cipher(ssl));
SSL_SESSION_set_protocol_version(sess, TLS1_3_VERSION);
*sessptr = sess;
return 1;
}

All error checking omitted for now, this is obviously just a sample.
When I try to connect to my server on the command line using s_client:

$ openssl s_client -connect 127.0.0.1:12345 -psk_identity foo -psk 001122

The server pukes:

PSK server SSL 0x62300100 identity foo len 3 sess (nil)
139933268309760:error:141F906E:SSL routines:tls_parse_ctos_psk:bad
extension:../ssl/statem/extensions_srvr.c:1267:

And I have no idea what that's supposed to mean.

I'm willing to update the documentation/manpage and create a PR, but I
don't understand it as-it right now. So any help getting me up to speed
would be greatly appreciated. Examples would be also extremely useful
for this.

All the best,
Johannes

AW: openssl and external card reader support in TLS

[Tobias.Wolf]

Our PKCS11 module development will discontinue and therefore I can`t use it 
anymore, but the idea is great and very interesting. 
To give more details we need a callback or similar mechanism to replace the 
signature created in Certificate TLS message with our signature coming from the 
card reader.

TLS handshake
..
S: Certificate Request
C: Certificate Verify --> here we want to hook in "Signature" and replace the 
value!
.

We tried already with the client callback

int (*client_cert_cb)(SSL *ssl, X509 **x509,
   EVP_PKEY **pkey));

But there it is mandatory to give in the private key which we don`t have, 
because that part is done by the card reader machine. 
I think the caller of the callback is doing later on a rsa sign processing with 
the private key and there I want to hook in!

Tobias Wolf, T-Systems

-Ursprüngliche Nachricht-
Von: openssl-users  Im Auftrag von Michael 
Wojcik
Gesendet: Dienstag, 22. Oktober 2019 17:00
An: openssl-users@openssl.org
Betreff: RE: openssl and external card reader support in TLS

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
> Behalf Of tobias.w...@t-systems.com
> Sent: Tuesday, October 22, 2019 07:03

> I need to implement support for the external authentication of a card 
> reader within a TLS handshake. We did this already with PKCS11 using 
> the C_Sign function and it is working fine.

> Now I need to implement the same functionality in another use case 
> with openssl for TLS handshake.

> My Question is there a callback I can use or do I need to implement my own 
> ENGINE?

OpenSSL includes a PKCS#11 engine. I've used it in the past to interact with 
some HSMs for cryptographic operations such as code signing. While some 
research and additional software may be required to get all the PKCS#11 ducks 
in a row, it sounds like you've already successfully used PKCS#11 with your 
device, so I'd expect using it with OpenSSL will be fairly straightforward.

You can find examples of using the openssl command-line utility with the 
PKCS#11 engine online. That's a good way to get started; it will let you 
confirm what settings and commands you need.

--
Michael Wojcik
Distinguished Engineer, Micro Focus