headers
derleader mail | 2 Oct 2011 15:12
Picon

how to generate certificate and key for examples

 Hi,
  I'm trying to test the sample TLS echo server and client, supporting X.509 and PSK
   authentication. The files are located in doc/examples - ex-serv-psk and ex-client-psk. I compiled them and I generate and certificate and key. But when I try to test them this message appears

*** Handshake failed
GnuTLS error: Insufficient credentials for that request.

It seems that the certificate is wrong. Can you tell me how to generate appropriate certificate and key.

Regards


-----------------------------------------------------------------
100 лв БОНУС. Най-високи коефициенти. Tempobet.com 
_______________________________________________
Help-gnutls mailing list
Help-gnutls <at> gnu.org
https://lists.gnu.org/mailman/listinfo/help-gnutls
Permalink | Reply | 0 comments |
headers
Erinn Looney-Triggs | 11 Oct 2011 04:24
Picon

Unable to process private key

I am receiving the following error when trying to use gnutls-cli:

gnutls-cli --x509cafile /etc/pki/certmaster/ca.cert --x509keyfile
foo.example.com.pem --x509certfile foo.example.com.cert -p 514
bar.example.com
Processed 1 CA certificate(s).
Processed 1 client certificates...
*** Error loading key file: Base64 decoding error.

I am able to successfully render the private key using openssl:

openssl rsa -noout -text -in <key>

Is their an equivalent command for gnutls?

However, I am unsure of what the problem with the key is that I am
looking for, any guidance would be greatly appreciated.

This is gnutls-2.8.5-4.el6.x86_64 on a RHEL 6 system.

Thanks,
-Erinn
Permalink | Reply | 5 comments |
headers
Moritz Wilhelmy | 11 Oct 2011 11:56
Picon
Favicon

Generating a certificate with multiple common names

Hello,

it isn't all too obvious to me from the documentation how to generate a
certificate with more than one CN with certtool(1), and what the
template file syntax for this looks like.

Maybe I'm not looking around enough, but just by quickly looking over
this list's archive I didn't find anything either.

The story behind this is that we have two second-level domains, and
want our certificates to be valid for both of them.

Is this possible at all? At least openssl seems to support it, but I
would prefer knowing how to do it with certtool.

Best regards,

Moritz Wilhelmy
Permalink | Reply | 1 comment |
headers
Nikos Mavrogiannopoulos | 11 Oct 2011 17:30

Re: Unable to process private key

On Tue, Oct 11, 2011 at 4:24 AM, Erinn Looney-Triggs
<erinn.looneytriggs <at> gmail.com> wrote:
> I am receiving the following error when trying to use gnutls-cli:
> gnutls-cli --x509cafile /etc/pki/certmaster/ca.cert --x509keyfile
> foo.example.com.pem --x509certfile foo.example.com.cert -p 514
> bar.example.com
> Processed 1 CA certificate(s).
> Processed 1 client certificates...
> *** Error loading key file: Base64 decoding error.

I suppose it is a base64 decoding error? It could be that there are
carriage returns, spaces or tabs in the PEM encoded file and gnutls
2.8.x doesn't like them.

> I am able to successfully render the private key using openssl:
> openssl rsa -noout -text -in <key>

openssl as well as Gnutls 2.12.x are more liberal in PEM (base64) decoding.

> Is their an equivalent command for gnutls?

Upgrade to 2.12.x or use openssl to convert the file to "correct"
encoding and then try loading again.

regards,
Nikos
Permalink | Reply | 4 comments |
headers
Erinn Looney-Triggs | 11 Oct 2011 18:34
Picon

Re: Unable to process private key

On 10/11/2011 07:30 AM, Nikos Mavrogiannopoulos wrote:
> On Tue, Oct 11, 2011 at 4:24 AM, Erinn Looney-Triggs
> <erinn.looneytriggs <at> gmail.com> wrote:
>> I am receiving the following error when trying to use gnutls-cli:
>> gnutls-cli --x509cafile /etc/pki/certmaster/ca.cert --x509keyfile
>> foo.example.com.pem --x509certfile foo.example.com.cert -p 514
>> bar.example.com
>> Processed 1 CA certificate(s).
>> Processed 1 client certificates...
>> *** Error loading key file: Base64 decoding error.
> I suppose it is a base64 decoding error? It could be that there are
> carriage returns, spaces or tabs in the PEM encoded file and gnutls
> 2.8.x doesn't like them.
>
>> I am able to successfully render the private key using openssl:
>> openssl rsa -noout -text -in <key>
> openssl as well as Gnutls 2.12.x are more liberal in PEM (base64) decoding.
>
>> Is their an equivalent command for gnutls?
> Upgrade to 2.12.x or use openssl to convert the file to "correct"
> encoding and then try loading again.
>
> regards,
> Nikos

Thanks, I dug into this further last night. I am no expert in this realm
but it looks like the problem lies in the fact that the key is in PKCS#8
format. With the version of gnutls I have on RHEL 6, certtool will
happily decode it automatically via certtool -k, however, gnutls-cli
will not, nor in fact will rsyslog which is what really drove me down
this path. Rsyslog simply crashes and core dumps. Rumor is that there is
a gnutls function that will automatically detect/decode pkcs#8 format,
but I have yet to find it or fully understand this situation, so I am
continuing to look. Again if you have any advice I would apprecciate it,
upgrading isn't much of an option at least in the short term, I may be
able to coax Red Hat into an upgrade but I doubt it.

-Erinn
Permalink | Reply | 3 comments |
headers
Nikos Mavrogiannopoulos | 11 Oct 2011 18:42

Re: Unable to process private key

On Tue, Oct 11, 2011 at 6:34 PM, Erinn Looney-Triggs
<erinn.looneytriggs <at> gmail.com> wrote:

> Thanks, I dug into this further last night. I am no expert in this realm
> but it looks like the problem lies in the fact that the key is in PKCS#8
> format.
> With the version of gnutls I have on RHEL 6, certtool will
> happily decode it automatically via certtool -k, however, gnutls-cli
> will not, nor in fact will rsyslog which is what really drove me down

Ah. In that case just use the output of certtool -k to gnutls-cli or
the program your want to use.

> this path. Rsyslog simply crashes and core dumps. Rumor is that there is
> a gnutls function that will automatically detect/decode pkcs#8 format,

If you used 2.12.x the decoder would have falled back to pkcs #8.

regards,
Nikos
Permalink | Reply | 2 comments |
headers
Nikos Mavrogiannopoulos | 11 Oct 2011 19:10

Re: Generating a certificate with multiple common names

On 10/11/2011 11:56 AM, Moritz Wilhelmy wrote:
> Hello,
>
> it isn't all too obvious to me from the documentation how to generate a
> certificate with more than one CN with certtool(1), and what the
> template file syntax for this looks like.

Using multiple CNs is not correct. You should use the dns_name
directive, and you can add as many as you like.

regards,
Nikos
Permalink | Reply | 0 comments |
headers
Erinn Looney-Triggs | 11 Oct 2011 19:37
Picon

Re: Unable to process private key

On 10/11/2011 08:42 AM, Nikos Mavrogiannopoulos wrote:
> On Tue, Oct 11, 2011 at 6:34 PM, Erinn Looney-Triggs
> <erinn.looneytriggs <at> gmail.com> wrote:
>
>> Thanks, I dug into this further last night. I am no expert in this realm
>> but it looks like the problem lies in the fact that the key is in PKCS#8
>> format.
>> With the version of gnutls I have on RHEL 6, certtool will
>> happily decode it automatically via certtool -k, however, gnutls-cli
>> will not, nor in fact will rsyslog which is what really drove me down
> Ah. In that case just use the output of certtool -k to gnutls-cli or
> the program your want to use.
>
>> this path. Rsyslog simply crashes and core dumps. Rumor is that there is
>> a gnutls function that will automatically detect/decode pkcs#8 format,
> If you used 2.12.x the decoder would have falled back to pkcs #8.
>
> regards,
> Nikos

So versions of gnutls < 2.12 will not automagically decode it? Just want
to make sure so I can figure out which direction to push Red Hat in (if
I can push them at all).

-Erinn
Permalink | Reply | 1 comment |
headers
Nikos Mavrogiannopoulos | 11 Oct 2011 20:10

Re: Unable to process private key

On 10/11/2011 07:37 PM, Erinn Looney-Triggs wrote:

> So versions of gnutls<  2.12 will not automagically decode it? Just want
> to make sure so I can figure out which direction to push Red Hat in (if
> I can push them at all).

This change occurred after 2.12.0.

regards,
Nikos
Permalink | Reply | 0 comments |
headers
Alfredo Pironti | 17 Oct 2011 17:59
Picon
Picon
Favicon

GCM Implementation and TLSCompressed.Length

Dear list,

I'm a post-doc researcher at INRIA, France, and I'm developing a TLS
implementation (with the goal of formal verification), and I would
like to include support for AEAD ciphers (e.g. AEAD_AES_128_GCM).
However, I got stuck because of the following problem.

According to RFC 5246, sec 6.2.3.3, the additional data (AD) for AEAD
consist of "seq_num + TLSCompressed.type + TLSCompressed.version +
TLSCompressed.length".
Computing such AD, and in particular TLSCompressed.length, is feasible
when encrypting. However, when decrypting it seems impossible to me to
retrieve that value (indeed it should be secret, and the AEAD
ciphertext should not reveal the size of the plaintext, right? After
all, in the Mac-then-encrypt mode of TLS, random padding is added for
this exact purpose -- and TLSCompressed.length becomes available only
after decryption, and before mac verification).

Can you please explain me where am I wrong?
I tried to take a quick look at the GnuTLS implementation of GCM (the
only open source TLS implementation I'm aware of implementing GCM),
but I could not find an evident mapping between the AEAD interface
described in RFC 5246 and the code, especially w.r.t. to the AD. Have
you got any hint about it?

Thank you very much in advance for your support.

Best,
Alfredo
Permalink | Reply | 3 comments |

Gmane