Problem with certificates

[welty]

Hello,

I'm trying to use iPXE with certificates but without success.
On the SOL, I have :
[undefined=undefined]...
000a6a14 : d0 d5 0d 22 27 ef 10 ec-4d 16 69 de f8 a1 c8 b1 : ..."'...M.i..... = 0x1
TLS 0x26534 found certificate m2-mn = 0x1
TLS 0x26534 found certificate diskless = 0x1
TLS 0x26534 certificate validation failed: Permission denied (http://ipxe.org/02= 0x1
16eb3c) = 0x1
Permission denied (http://ipxe.org/0216eb3c) = 0x1
Could not boot image: Permission denied (http://ipxe.org/0216eb3c) = 0x1
No more network devices [/undefined]

diskless is the CA certificate and m2-mn is the server one.

And on the server :
[undefined=undefined]==> /var/log/httpd/ssl_error_log <==
[Tue May 27 09:25:24.148528 2014] [ssl:info] [pid 37740] [client 172.29.40.128:47987] AH01964: Connection to child 4 established (server m2-mn:443)
[Tue May 27 09:25:24.148984 2014] [ssl:debug] [pid 37740] ssl_engine_kernel.c(1913): [client 172.29.40.128:47987] AH02043: SSL virtual host for servername m2-mn found
[Tue May 27 09:25:24.266356 2014] [ssl:debug] [pid 37740] ssl_engine_io.c(1201): (70014)End of file found: [client 172.29.40.128:47987] AH02007: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
[Tue May 27 09:25:24.266391 2014] [ssl:info] [pid 37740] [client 172.29.40.128:47987] AH01998: Connection closed to child 4 with abortive shutdown (server m2:443)[/undefined]

I follow all directives from the iPXE.

Do you have any tips that I can try ?

Thank's a lot !

Regards
Welty

[robinsmidsrod]

The error message you see on http://ipxe.org/err/0216eb says "no usable certificates". My guess is that you've not followed the instructions on http://ipxe.org/crypto exactly, and you don't have a proper certificate signature embedded inside your iPXE binary that is trusted that matches what the web server is sending. If you try with a normal web browser, is the correct certificate being sent to the client?

It might also be that you're using SSL virtual-hosting, and not a dedicated IP for each SSL certificate, which I believe requires support for the TLS 1.2 hostname extension. It is commonplace to be present in browsers, but I'm unsure if iPXE supports it.

[mcb30]

(2014-05-28 07:59)welty Wrote:  I'm trying to use iPXE with certificates but without success.

What command line did you use to build your iPXE binary?

Michael

[welty]

Hello !

Thanks for the quick answer !

I think I use TLS V1 because of :
[undefined=undefined][Mon Jun 02 13:55:00.445305 2014] [ssl:debug] [pid 26578] ssl_engine_kernel.c(1846): [client 172.29.40.129:42572] AH02041: Protocol: TLSv1, Cipher: ECDHE-RSA-AES256-SHA (256/256 bits)[/undefined]
with a wget client (not ipxe) : wget --no-check-certificate --private-key=client.key --verbose --ca-certificate=ca.crt --certificate=client.crt https://m2-mn/file

The command line used to generate the binary is :
[undefined=undefined]make DEBUG=tls bin/undionly.kpxe CERT=/diskless/certs/client.crt,/diskless/certs/ca.crt TRUST=/diskless/certs/ca.crt[/undefined]

I generate the certificates with this script (thanks to another post on this forum!)
[undefined=undefined]#!/bin/bash
CERT_DIR=/diskless/certs

cd $CERT_DIR
rm -rf signed/ ca.idx ca.idx.attr ca.idx.attr.old ca.idx.old

rm sslpass
echo pass >> sslpass
echo pass >> sslpass

echo
echo ============================================================================
echo
echo ' Creating CA Certificate'
echo
echo ============================================================================
echo

# CREATE ROOT Certificate
openssl req -x509 -newkey rsa:2048 -out ca.crt -keyout ca.key -days 3650 \
-subj "/C=FR/ST=Isere/L=Grenoble/O=B/CN=diskless" \
-passin file:sslpass -passout file:sslpass

echo
echo ============================================================================
echo
echo ' Creating SERVER Certificate'
echo
echo ============================================================================
echo


cat << EOF >> ca.cnf
[ ca ]
default_ca = ca_default

[ ca_default ]
certificate = ca.crt
private_key = ca.key
serial = ca.srl
database = ca.idx
new_certs_dir = signed
default_md = default
policy = policy_anything
preserve = yes
default_days = 90
unique_subject = no

[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = optional
emailAddress = optional

[ cross ]
basicConstraints = critical,CA:true
keyUsage = critical,cRLSign,keyCertSign

[ codesigning ]
keyUsage = digitalSignature
extendedKeyUsage = codeSigning
EOF

echo 01 > ca.srl
touch ca.idx
mkdir signed

# CREATE Certificate
openssl req -newkey rsa:2048 -keyout server.key -out server.req \
-subj "/C=FR/ST=Isere/L=Grenoble/O=Bull/CN=m2-mn" \
-passin file:sslpass -passout file:sslpass

# SIGN Certificate using CA Certificate
openssl ca -config ca.cnf -in server.req -out server.crt \
-passin file:sslpass -batch

echo
echo ============================================================================
echo
echo ' Creating CODE SIGN Certificate'
echo
echo ============================================================================
echo

# CREATE Certificate
openssl req -newkey rsa:2048 -keyout codesign.key -out codesign.req \
-subj "/C=FR/ST=Isere/L=Grenoble/O=Bull/CN=m2-mn" \
-passin file:sslpass -passout file:sslpass

# SIGN Certificate using CA Certificate
openssl ca -config ca.cnf -extensions codesigning -in codesign.req -out codesign.crt \
-passin file:sslpass -batch


echo
echo ============================================================================
echo
echo ' Creating CLIENT Certificate'
echo
echo ============================================================================
echo

# CREATE Certificate
openssl req -newkey rsa:2048 -keyout client.key -out client.req \
-subj "/C=FR/ST=Isere/L=Grenoble/O=B/CN=m44-mn" \
-passin file:sslpass -passout file:sslpass

# SIGN Certificate using CA Certificate
openssl ca -config ca.cnf -in client.req -out client.crt \
-passin file:sslpass -batch

echo
echo ============================================================================
echo
echo ' Removing Passwords'
echo
echo ============================================================================
echo

cp ca.key ca.key.org
openssl rsa -in ca.key.org -out ca.key \
-passin file:sslpass

cp server.key server.key.org
openssl rsa -in server.key.org -out server.key \
-passin file:sslpass

cp client.key client.key.org
openssl rsa -in client.key.org -out client.key \
-passin file:sslpass

cp codesign.key codesign.key.org
openssl rsa -in codesign.key.org -out codesign.key \
-passin file:sslpass


[/undefined]


thanks a lot for your help !
Regards,

Benoit

[mcb30]

(2014-06-02 13:08)welty Wrote:  The command line used to generate the binary is :

Code:

make DEBUG=tls bin/undionly.kpxe CERT=/diskless/certs/client.crt,/diskless/certs/ca.crt  TRUST=/diskless/certs/ca.crt

That looks plausibly correct.

Quote:I generate the certificates with this script (thanks to another post on this forum!)

Please use the instructions on http://ipxe.org/crypto instead, since these have been verified as correct. Let us know if you still have problems after following those instructions.

Michael

[welty]

Thanks for the answer.
I use a script because I made lot of tests ...
I retried from http://ipxe.org/crypto to be sure and now, I have another problem already seen here : http://forum.ipxe.org/printthread.php?tid=6855
I tried the solution to add "SSLRequire %{SSL_CLIENT_S_DN_O} eq xx " but no success ...

On the serial line :
[undefined=undefined]TLS 0x26554 RX IV: = 0x1
000a69b8 : 81 e3 18 94 18 59 18 c3-5e a1 73 66 73 f3 9d 2b : .....Y..^.sfs..+ = 0x1
TLS 0x26554 found certificate am2-mn.bx = 0x1
TLS 0x26554 found certificate diskless = 0x1
TLS 0x26554 certificate validation succeeded = 0x1
TLS 0x26554 received fatal alert 40 = 0x1
Operation not permitted (http://ipxe.org/410de13c) = 0x1
Could not boot image: Operation not permitted (http://ipxe.org/410de13c) = 0x1
No more network devices [/undefined]


On server side :
[Tue Jun 03 10:03:29.873348 2014] [socache_shmcb:debug] [pid 5107] mod_socache_shmcb.c(485): AH00831: socache_shmcb_store (0x21 -> subcache 1)
[Tue Jun 03 10:03:29.873374 2014] [socache_shmcb:debug] [pid 5107] mod_socache_shmcb.c(810): AH00847: insert happened at idx=0, data=(0:32)
[Tue Jun 03 10:03:29.873379 2014] [socache_shmcb:debug] [pid 5107] mod_socache_shmcb.c(815): AH00848: finished insert, subcache: idx_pos/idx_used=0/1, data_pos/data_used=0/198
[Tue Jun 03 10:03:29.873420 2014] [socache_shmcb:debug] [pid 5107] mod_socache_shmcb.c(506): AH00834: leaving socache_shmcb_store successfully
[Tue Jun 03 10:03:29.873474 2014] [ssl:debug] [pid 5107] ssl_engine_kernel.c(1846): [client 172.29.40.128:1023] AH02041: Protocol: TLSv1, Cipher: AES256-SHA (256/256 bits)
[Tue Jun 03 10:03:29.873542 2014] [ssl:debug] [pid 5107] ssl_engine_kernel.c(224): [client 172.29.40.128:1023] AH02034: Initial (No.1) HTTPS request received for child 2 (server m2-mn.bx:443)
[Tue Jun 03 10:03:29.873708 2014] [ssl:debug] [pid 5107] ssl_engine_kernel.c(572): [client 172.29.40.128:1023] AH02255: Changed client verification type will force renegotiation
[Tue Jun 03 10:03:29.873719 2014] [ssl:info] [pid 5107] [client 172.29.40.128:1023] AH02221: Requesting connection re-negotiation
[Tue Jun 03 10:03:29.873737 2014] [ssl:debug] [pid 5107] ssl_engine_kernel.c(772): [client 172.29.40.128:1023] AH02260: Performing full renegotiation: complete handshake protocol (client does not support secure renegotiation)
[Tue Jun 03 10:03:29.873770 2014] [ssl:error] [pid 5107] [client 172.29.40.128:1023] AH02225: Re-negotiation request failed
[Tue Jun 03 10:03:29.873795 2014] [ssl:error] [pid 5107] SSL Library Error: error:14080152:SSL routines:SSL3_ACCEPT:unsafe legacy renegotiation disabled
[Tue Jun 03 10:03:29.873862 2014] [ssl:info] [pid 5107] (11)Resource temporarily unavailable: [client 172.29.40.128:1023] AH02008: SSL library error 1 in handshake (server m2-mn.bx:443)
[Tue Jun 03 10:03:29.873891 2014] [ssl:info] [pid 5107] SSL Library Error: error:14080152:SSL routines:SSL3_ACCEPT:unsafe legacy renegotiation disabled
[Tue Jun 03 10:03:29.873898 2014] [ssl:info] [pid 5107] [client 172.29.40.128:1023] AH01998: Connection closed to child 2 with abortive shutdown (server m2-mn.bx:443)

And with a wget client :
ue Jun 03 10:09:46.726666 2014] [ssl:debug] [pid 5577] ssl_engine_kernel.c(1913): [client 172.29.40.129:38639] AH02043: SSL virtual host for servername m2-mn.bx found
[Tue Jun 03 10:09:46.737686 2014] [ssl:debug] [pid 5577] ssl_engine_kernel.c(1846): [client 172.29.40.129:38639] AH02041: Protocol: TLSv1, Cipher: ECDHE-RSA-AES256-SHA (256/256 bits)
[Tue Jun 03 10:09:46.738059 2014] [ssl:debug] [pid 5577] ssl_engine_kernel.c(224): [client 172.29.40.129:38639] AH02034: Initial (No.1) HTTPS request received for child 1 (server m2-mn.bx:443)
[Tue Jun 03 10:09:46.738175 2014] [ssl:debug] [pid 5577] ssl_engine_kernel.c(572): [client 172.29.40.129:38639] AH02255: Changed client verification type will force renegotiation
[Tue Jun 03 10:09:46.738185 2014] [ssl:info] [pid 5577] [client 172.29.40.129:38639] AH02221: Requesting connection re-negotiation
[Tue Jun 03 10:09:46.738202 2014] [ssl:debug] [pid 5577] ssl_engine_kernel.c(772): [client 172.29.40.129:38639] AH02260: Performing full renegotiation: complete handshake protocol (client does support secure renegotiation)
[Tue Jun 03 10:09:46.738238 2014] [ssl:info] [pid 5577] [client 172.29.40.129:38639] AH02226: Awaiting re-negotiation handshake
[Tue Jun 03 10:09:46.738475 2014] [ssl:debug] [pid 5577] ssl_engine_kernel.c(1913): [client 172.29.40.129:38639] AH02043: SSL virtual host for servername m2-mn.bx found
[Tue Jun 03 10:09:46.752408 2014] [ssl:debug] [pid 5577] ssl_engine_kernel.c(1383): [client 172.29.40.129:38639] AH02275: Certificate Verification, depth 1, CRL checking mode: none [subject: CN=diskless,O=Bx,L=Grenoble,ST=Isere,C=FR / issuer: CN=diskless,O=Bx,L=Grenoble,ST=Isere,C=FR / serial: E0FB8BD9EB99D6B8 / notbefore: Jun 3 07:00:12 2014 GMT / notafter: Feb 27 07:00:12 2017 GMT]
[Tue Jun 03 10:09:46.752519 2014] [ssl:debug] [pid 5577] ssl_engine_kernel.c(1383): [client 172.29.40.129:38639] AH02275: Certificate Verification, depth 0, CRL checking mode: none [subject: CN=rama44-mn.bullx,O=Bx,L=Grenoble,ST=Isere,C=FR / issuer: CN=diskless,O=Bx,L=Grenoble,ST=Isere,C=FR / serial: 02 / notbefore: Jun 3 07:49:16 2014 GMT / notafter: Sep 1 07:49:16 2014 GMT]
[Tue Jun 03 10:09:46.753475 2014] [ssl:debug] [pid 5577] ssl_engine_kernel.c(1846): [client 172.29.40.129:38639] AH02041: Protocol: TLSv1, Cipher: ECDHE-RSA-AES256-SHA (256/256 bits)
[Tue Jun 03 10:09:46.753505 2014] [authz_core:debug] [pid 5577] mod_authz_core.c(802): [client 172.29.40.129:38639] AH01626: authorization result of Require all granted: granted
[Tue Jun 03 10:09:46.753511 2014] [authz_core:debug] [pid 5577] mod_authz_core.c(802): [client 172.29.40.129:38639] AH01626: authorization result of <RequireAny>: granted

Thank you for any help !

Regards

Welty

[welty]

Little update :

I can know use server side certificate but not client.
I try with the option "SSLVerifyClient require" and receive "TLS 0x26554 received fatal alert 40"

Thanks

Welty

[mcb30]

(2014-06-03 10:24)welty Wrote:  I can know use server side certificate but not client.
I try with the option "SSLVerifyClient require" and receive "TLS 0x26554 received fatal alert 40"

What command line are you now using to build your iPXE binary?

If you are still using the same command line as before then you have omitted the PRIVKEY= parameter which specifies the client's private key. See http://ipxe.org/crypto#client_certificates.

Michael

[welty]

Hello

I'm using this command :
make DEBUG=tls bin/undionly.kpxe PRIVKEY=/diskless/new_certs/client.key TRUST=/diskless/new_certs/ca.crt CERT=/diskless/new_certs/client.crt,/diskless/new_certs/ca.crt

How can I check that the certificate is included in the iPXE binary ?

Thanks

Benoit

[mcb30]

(2014-06-03 11:53)welty Wrote:  I'm using this command :
make DEBUG=tls bin/undionly.kpxe PRIVKEY=/diskless/new_certs/client.key TRUST=/diskless/new_certs/ca.crt CERT=/diskless/new_certs/client.crt,/diskless/new_certs/ca.crt

How can I check that the certificate is included in the iPXE binary ?

If you build with DEBUG=tls,x509,certstore,privkey then you should see debug messages mentioning the embedded certificates and keys.

Michael

[welty]

(2014-06-11 20:15)mcb30 Wrote:  

(2014-06-03 11:53)welty Wrote:  I'm using this command :
make DEBUG=tls bin/undionly.kpxe PRIVKEY=/diskless/new_certs/client.key TRUST=/diskless/new_certs/ca.crt CERT=/diskless/new_certs/client.crt,/diskless/new_certs/ca.crt

How can I check that the certificate is included in the iPXE binary ?

If you build with DEBUG=tls,x509,certstore,privkey then you should see debug messages mentioning the embedded certificates and keys.

Michael

Thank you for the help, I have more messages but I can't make SSL work:

...
;40mCERTSTORE added certificate rama44
;32;40mCERTSTORE permanent certificate 0 is rama44
3;01HCERTSTORE added certificate diskless
4;01HCERTSTORE permanent certificate 1 is diskless
;37;40miPXE initialising devices...
...
;32;40m added certificate rama2-mn
;35;40m0xa94f0 "diskless" is
;36;40mx" successfully validated using issuer 0xa94f0 diskless"
;33;40mTLS 0x2a5d4 certificate validation succeeded
...
;32;40mCERTSTORE added certificate rama2-mn
;34;40mX509 chain 0x29704 added X509 0x2ad74 "rama2-mn"
;33;40mTLS 0x2a5d4 found certificate rama2-mn
4;01HX509 chain 0x29704 added X509 0xa94f0 "diskless"
5;01HTLS 0x2a5d4 found certificate diskless
;35;40mX509 0xa94f0 "diskless" is a root certificate
;36;40mX509 0x2ad74 "rama2-mn" successfully validated using issuer 0xa94f0 "diskl
8;01Hess"
;33;40mTLS 0x2a5d4 certificate validation succeeded
;33;40mTLS 0x2a5d4 received fatal alert 40
1;01H
;37;40m Operation not permitted (http://ipxe.org/410de13c)
;33;40m
2;01H
;37;40mCould not boot image: Operation not permitted (http://ipxe.org/410de13c)
3;01HNo more network devices
4;01H
5;01HPress Ctrl-B for the iPXE command line...
...

Is there a problem with my apache conf ? It works with a wget client !

Thank you !

Regards

Welty

[mcb30]

(2014-06-12 15:25)welty Wrote:  

(2014-06-11 20:15)mcb30 Wrote:  If you build with DEBUG=tls,x509,certstore,privkey then you should see debug messages mentioning the embedded certificates and keys.

Thank you for the help, I have more messages but I can't make SSL work:

Did you see any messages of the form

Code:

PRIVKEY using built-in private key

If not, then your private key is somehow not being included within the build.

With DEBUG=privkey enabled, you should always get at least one debug message mentioning "PRIVKEY", even if no keys are present.

Michael

[welty]

Hello,

I have some messages of this type in the unclear stream :
"
PRIVKEY using built-in pri ....
PRIVKEY using built-in 02 01 00 02-82 01 01 00 b7 44 5e 65
....
PRIVKEY using b2 04 a3 02 01 00 02-82 01 01 00 b7 44 5e 65 : 0...P...6..9..f. ^[
14;01H00000020 : 18 4e 8d 9e ba 60 33 de-6d a7 2d fe 73 7a c5 d9 : ....{.....v...K. ^[
15;01H00000060 : 2a d0 7b 45 4b 40 d3 1a-6e 2d 97 6a 4a c9 68 9f : ......sbn....E.. ^[
16;01H00000090 : e0 76 32 26 01 f7 13 d9-41 62 83 65 3a 92 b9 8d : .r.X..LW.|:..... ^[
17;01H000000d0 : ae 0a ee 29 b8 33 6e 0d-df c0 9a 23 d2 42 fd 10 : .GR.i......#.B.. ^[
...

This suggests that the key is included.

Any suggestion welcome :-)

Thanks !

Regards

Benoit

[mcb30]

(2014-06-17 14:29)welty Wrote:  PRIVKEY using built-in pri ....
PRIVKEY using built-in 02 01 00 02-82 01 01 00 b7 44 5e 65
....
PRIVKEY using b2 04 a3 02 01 00 02-82 01 01 00 b7 44 5e 65 : 0...P...6..9..f. ^[
14;01H00000020 : 18 4e 8d 9e ba 60 33 de-6d a7 2d fe 73 7a c5 d9 : ....{.....v...K. ^[
15;01H00000060 : 2a d0 7b 45 4b 40 d3 1a-6e 2d 97 6a 4a c9 68 9f : ......sbn....E.. ^[
16;01H00000090 : e0 76 32 26 01 f7 13 d9-41 62 83 65 3a 92 b9 8d : .r.X..LW.|:..... ^[
17;01H000000d0 : ae 0a ee 29 b8 33 6e 0d-df c0 9a 23 d2 42 fd 10 : .GR.i......#.B.. ^[
...

Your key is definitely included within the binary. I think this is the question that you were asking.

Incidentally, your debug output looks extremely garbled. How are you capturing this output?

Michael

[welty]

(2014-06-17 15:03)mcb30 Wrote:  Your key is definitely included within the binary. I think this is the question that you were asking.

Incidentally, your debug output looks extremely garbled. How are you capturing this output?

Michael

Hello,

Thanks for the reply. I'm back on this subject. The output comes from the serial over lan.

Could you please confirm that iPXE supports "full renegotiation" ? Because the difference between wget and iPXE is :
AH02260: Performing full renegotiation: complete handshake protocol (client does not support secure renegotiation)
VS
Performing full renegotiation: complete handshake protocol (client does support secure renegotiation)

Thanks !

Welty

[mcb30]

(2014-07-21 15:09)welty Wrote:  

(2014-06-17 15:03)mcb30 Wrote:  Incidentally, your debug output looks extremely garbled. How are you capturing this output?

Thanks for the reply. I'm back on this subject. The output comes from the serial over lan.

OK. Your serial over LAN support appears to be somewhat broken: large numbers of characters are missing. You might get better results by using iPXE's syslog support.

Quote:Could you please confirm that iPXE supports "full renegotiation" ? Because the difference between wget and iPXE is :
AH02260: Performing full renegotiation: complete handshake protocol (client does not support secure renegotiation)
VS
Performing full renegotiation: complete handshake protocol (client does support secure renegotiation)

Renegotiation is an optional part of TLS, and is not supported by iPXE. Since it is optional, servers should never be configured to require renegotiation.

Michael

[welty]

Quote:Could you please confirm that iPXE supports "full renegotiation" ? Because the difference between wget and iPXE is :
AH02260: Performing full renegotiation: complete handshake protocol (client does not support secure renegotiation)
VS
Performing full renegotiation: complete handshake protocol (client does support secure renegotiation)

Renegotiation is an optional part of TLS, and is not supported by iPXE. Since it is optional, servers should never be configured to require renegotiation.

Michael

[/quote]

Thanks for the reply.

Here is the log of the connexion :

sleeping 3 sec
.
https://http.srv.bx//tftpboot_per_node/r...x86_64...^[[33mTLS 0xe56d4 using protocol version 3.3
^[[0m^[[33mTLS 0xe56d4 selected rsa-aes_cbc-256-sha256
^[[0m^[[33mTLS 0xe56d4 pre-master-secret:
^[[0m^[[33m000e575c : 03 03 c4 1d b4 eb 29 b6-11 e8 07 64 6b 50 67 74 : ......)....dkPgt
000e576c : ae a3 f0 f7 67 fd d4 22-91 58 a2 32 17 b7 48 87 : ....g..".X.2..H.
000e577c : f9 4d af 3a ab 11 99 3e-5c 3a b3 b8 0d 24 06 16 : .M.:...>\:...$..
^[[0m^[[33mTLS 0xe56d4 client random bytes:
^[[0m^[[33m000e57dc : 24 7f ce 53 93 43 63 e8-97 4a d2 a2 fd 5a 35 50 : $..S.Cc..J...Z5P
000e57ec : 85 87 65 31 82 d4 bc 85-55 13 18 5f 57 83 3a 52 : ..e1....U.._W.:R
^[[0m^[[33mTLS 0xe56d4 server random bytes:
^[[0m^[[33m000e57bc : 53 ce 7f 0e bb 81 14 c6-18 d8 e3 64 2a 2c f3 fe : S..........d*,..
000e57cc : d1 ba e2 9d ee a6 98 05-11 83 98 18 6f 05 d7 ce : ............o...
^[[0m^[[33mTLS 0xe56d4 generated master secret:
^[[0m^[[33m000e578c : 84 fb ce 25 e1 51 11 51-5a 62 1e c8 33 a5 d8 48 : ...%.Q.QZb..3..H
000e579c : ca e5 23 3a 31 63 55 ab-00 f0 4c 0d 43 f8 ae 40 : ..#:1cU...L.C..@
000e57ac : c4 95 a0 27 c1 d1 38 0c-3e 42 55 db d5 39 b6 bf : ...'..8.>BU..9..
^[[0m^[[33mTLS 0xe56d4 TX MAC secret:
^[[0m^[[33m00170bec : e1 18 a3 2d 64 4f 32 96-3b 5c 50 22 58 40 05 12 : ...-dO2.;\P"X@..
00170bfc : 9a 34 e4 1c 38 de 7c 5a-0a c2 98 20 d6 29 22 65 : .4..8.|Z... .)"e
^[[0m^[[33mTLS 0xe56d4 RX MAC secret:
^[[0m^[[33m00170c0c : ff 3f 4e 97 65 24 38 b7-da 30 2a bb be 77 b5 ea : .?N.e$8..0*..w..
00170c1c : 69 2b 2b a6 b2 cf 34 4d-fd 32 28 36 78 02 a4 74 : i++...4M.2(6x..t
^[[0m^[[33mTLS 0xe56d4 TX key:
^[[0m^[[33m00170c2c : e9 32 51 f5 d7 2a 25 38-78 d8 da 46 cf 07 7a 23 : .2Q..*%8x..F..z#
00170c3c : c4 47 9a 82 32 83 8b 9e-db 50 41 fa 86 39 03 22 : .G..2....PA..9."
^[[0m^[[33mTLS 0xe56d4 RX key:
^[[0m^[[33m00170c4c : 8f c4 10 c2 68 12 5a 1f-2d 55 de fd ad c5 77 e1 : ....h.Z.-U....w.
00170c5c : 04 98 a1 a8 7f a5 a5 a0-a9 e5 a0 4b 0d 4a 7c 41 : ...........K.J|A
^[[0m^[[33mTLS 0xe56d4 TX IV:
^[[0m^[[33m00170c6c : 5c f8 60 40 29 97 3a 79-65 83 e6 f8 ae 7a 43 b9 : \.`@).:ye....zC.
^[[0m^[[33mTLS 0xe56d4 RX IV:
^[[0m^[[33m00170c7c : 0a aa 5a 56 13 90 27 e2-9d ee 54 2a b2 4e b6 b3 : ..ZV..'...T*.N..
^[[0m^[[32mCERTSTORE added certificate http.srv.bx
^[[0m^[[34mX509 chain 0xe43a4 added X509 0xe5ce4 "http.srv.bx"
^[[0m^[[33mTLS 0xe56d4 found certificate http.srv.bx
^[[0m^[[34mX509 chain 0xe43a4 added X509 0x15cb98 "DisklessRootCA"
^[[0m^[[33mTLS 0xe56d4 found certificate DisklessRootCA
^[[0m^[[35mX509 0x15cb98 "DisklessRootCA" is a root certificate
^[[0m^[[36mX509 0xe5ce4 "http.srv.bx" successfully validated using ^[[0m^[[36missuer 0x15cb98 "DisklessRootCA"
^[[0m^[[33mTLS 0xe56d4 certificate validation succeeded
^[[0m^[[33mTLS 0xe56d4 ignoring handshake type 0
^[[0m.................... Connection reset (http://ipxe.org/0f0c6039)
Could not boot image: Connection reset (http://ipxe.org/0f0c6039)
No more network devices

!ignoring handshake type 0!

iPXE with http over SSL works well in its standard usage: the fact for a client to trust the connection with the server thanks to the root certificate embedded with the ipxe binary in order to get a trusted enciphered communication between those peers. But when we also embed client certificate (with a private key without passphrase) to authenticate it, it seems that the use of SSLVerifyClient in Apache (which is necessary to authenticate the client) leads to a SSL renegociation (this happens each time and we have no idea to avoid this behaviour). Since you say it is an optional feature of TLS and not implemented into ipxe, could we consider the client authentification is not a feature which is available in ipxe ?
Or could you please give me a apache configuration to test, because I'm lost :-(
https://devcentral.f5.com/articles/ssl-p...egotiation

Thanks a lot !

Welty

[mcb30]

(2014-07-22 16:17)welty Wrote:  iPXE with http over SSL works well in its standard usage: the fact for a client to trust the connection with the server thanks to the root certificate embedded with the ipxe binary in order to get a trusted enciphered communication between those peers. But when we also embed client certificate (with a private key without passphrase) to authenticate it, it seems that the use of SSLVerifyClient in Apache (which is necessary to authenticate the client) leads to a SSL renegociation (this happens each time and we have no idea to avoid this behaviour). Since you say it is an optional feature of TLS and not implemented into ipxe, could we consider the client authentification is not a feature which is available in ipxe ?
Or could you please give me a apache configuration to test, because I'm lost :-(

Client certificate authentication does work, at least the last time I tested it.

Could you post the contents of all applicable .htaccess files within the path to the URI you are trying to access with iPXE?

In particular, do you have a SSLCipherSuite directive within any .htaccess file?

Michael

[welty]

Hello,

I have no .htaccess.
Here is the ssl.conf configuration :

...
SSLCipherSuite ALL
...
LogLevel debug
#SSLInsecureRenegotiation on
Alias /tftpboot_per_node/ /tftpboot_per_node/
<Directory /tftpboot_per_node/rama44>
SSLVerifyClient require
SSLVerifyDepth 1
#SSLOptions +FakeBasicAuth
#+StrictRequire
#+OptRenegotiate
#SSLRequireSSL
##SSLRequire %{SSL_CLIENT_S_DN_O} eq "rama44-mn.bx"
#SSLRequire %{SSL_CLIENT_S_DN_CN} eq "rama44.bx"
#AuthType Basic
#AuthName "diskless"
#AuthBasicProvider file
#AuthUserFile /etc/httpd/conf/httpd.passwd.rama44-mn
#Require valid-user
Require all granted
</Directory>

Thanks for the help !

Welty

[welty]

woowwwww, it works with "SSLVerifyClient require" and "SSLVerifyDepth 1" directives outside of the <Directory> !!
Thanks very much for the help !

Hope this thread will help someone else !

Welty