mainGnuTLS - Support: sr #107540, iPhone/iPad TLS negotiation to...

 
 

sr #107540: iPhone/iPad TLS negotiation to postfix fails with certtool certs, works with openssl certs

Submitter:  Michael Rommel <mr2147>
Submitted:  Sat 04 Dec 2010 09:07:35 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  2 - Minor Status:  Done
Privacy:  Public Assigned to:  nmav
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 08 Dec 2010 10:10:13 PM UTC, comment #12: 

gnutls 2.10.4 should have solved those issues. If there is any other issue remaining please reopen the bug. Thank you for the detailed report and investigation!

Nikos Mavrogiannopoulos <nmav>
Group administrator
Wed 08 Dec 2010 09:26:38 PM UTC, comment #11: 

Hello,

during debugging, I tried to apply the same patch in a second location for the SignatureAlgorithm just after the Subject:

Line 1181 in lib/x509/common.c

     /* result = asn1_write_value (dst, name, NULL, 0); */
     result = asn1_write_value (dst, name, "\x05\x00", 2);

This turned out to work. Now the certificate is accepted and displayed for acceptance.

RFC3279 states:
The ASN.1 object identifier used to identify this signature algorithm is:

     sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-1(1) 5  }

When any of these three OIDs appears within the ASN.1 type AlgorithmIdentifier, the parameters component of that type SHALL be the ASN.1 type NULL.

It might be, that these two insertations are needed to conform to the RFC3279.

Hopefully this does not break anything else.

  Michael.


Michael Rommel <mr2147>
Sun 05 Dec 2010 11:39:50 AM UTC, comment #10: 

No, also with freshly generated new 1024 bit private keys, the symptom is the same. :-( Thanks for your effort, I know that it is most probably not a certtool issue, rather an Apple one.

Michael Rommel <mr2147>
Sun 05 Dec 2010 11:36:02 AM UTC, comment #9: 

Oh, do I have to re-generate the keys, too? I'll try that, hang on....

Michael Rommel <mr2147>
Sun 05 Dec 2010 11:35:02 AM UTC, comment #8: 

I tried the patch, suceeded, made clean and rebuilt.

Generated new ca, request and cert, steps described below.
Unfortunately the error is the same as before.

Logfile:

Dec  5 12:33:02 pelican postfix/smtpd[20910]: connect from parrot-wlan.layer-7.net[192.168.1.137]
Dec  5 12:33:03 pelican postfix/smtpd[20910]: setting up TLS connection from parrot-wlan.layer-7.net[192.168.1.137]
Dec  5 12:33:03 pelican postfix/smtpd[20910]: parrot-wlan.layer-7.net[192.168.1.137]: TLS cipher list "ALL:+RC4:@STRENGTH:!aNULL"
Dec  5 12:33:03 pelican postfix/smtpd[20910]: SSL_accept:before/accept initialization
Dec  5 12:33:03 pelican postfix/smtpd[20910]: SSL_accept:SSLv3 read client hello B
Dec  5 12:33:03 pelican postfix/smtpd[20910]: SSL_accept:SSLv3 write server hello A
Dec  5 12:33:03 pelican postfix/smtpd[20910]: SSL_accept:SSLv3 write certificate A
Dec  5 12:33:03 pelican postfix/smtpd[20910]: SSL_accept:SSLv3 write certificate request A
Dec  5 12:33:03 pelican postfix/smtpd[20910]: SSL_accept:SSLv3 flush data
Dec  5 12:33:03 pelican postfix/smtpd[20910]: SSL_accept:SSLv3 read client certificate A
Dec  5 12:33:03 pelican postfix/smtpd[20910]: SSL_accept:SSLv3 read client key exchange A
Dec  5 12:33:03 pelican postfix/smtpd[20910]: SSL3 alert write:fatal:bad record mac
Dec  5 12:33:03 pelican postfix/smtpd[20910]: SSL_accept:error in SSLv3 read certificate verify A
Dec  5 12:33:03 pelican postfix/smtpd[20910]: SSL_accept error from parrot-wlan.layer-7.net[192.168.1.137]: -1
Dec  5 12:33:03 pelican postfix/smtpd[20910]: warning: TLS library problem: 20910:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:422:
Dec  5 12:33:03 pelican postfix/smtpd[20910]: lost connection after STARTTLS from parrot-wlan.layer-7.net[192.168.1.137]
Dec  5 12:33:03 pelican postfix/smtpd[20910]: disconnect from parrot-wlan.layer-7.net[192.168.1.137]



Steps I took:

root@pelican:~/source/gnutls-2.10.3# !521
/root/source/gnutls-2.10.3/src/certtool --generate-self-signed --load-privkey /etc/ssl/gnutls/ca.key --template /etc/ssl/gnutls/ca.info --outfile /etc/ssl/gnutls/ca.pem
Generating a self signed certificate...
X.509 Certificate Information:
Version: 3
Serial Number (hex): 4cfb777e
Validity:
Not Before: Sun Dec 05 11:29:02 UTC 2010
Not After: Mon Dec 05 11:29:02 UTC 2011
Subject: C=DE,O=Layer-7 Technologies,OU=TLS Security,L=Erlangen,ST=Bavaria,CN=Root Certification Authority #2
Subject Public Key Algorithm: RSA
Modulus (bits 1024):
de:14:6f:4f:ad:a5:f1:75:46:ec:8e:3d:52:8b:88:61
f6:a2:b1:3b:f8:ff:58:91:9d:7e:fc:ff:95:d6:f5:8c
aa:71:a5:f7:35:ce:c4:c1:78:5d:be:e6:77:3a:15:8e
c4:b4:60:3f:cc:08:04:47:87:9f:7f:89:1b:3e:15:c2
55:83:d4:8f:bf:55:10:31:80:28:66:5e:b6:4f:ec:2d
e7:8a:c2:f1:57:00:89:6a:ed:58:90:f2:5b:da:ac:bc
74:41:b6:93:7e:91:d0:34:55:0a:be:39:ec:5d:08:a0
c2:c8:fb:6c:9f:f1:61:c1:ed:25:d8:52:62:98:25:ad
Exponent (bits 24):
01:00:01
Extensions:
Basic Constraints (critical):
Certificate Authority (CA): TRUE
Key Usage (critical):
Certificate signing.
Subject Key Identifier (not critical):
8d07623adb759d8e6bb26bf7f3e77adfb6bb42f2
Other Information:
Public Key Id:
8d07623adb759d8e6bb26bf7f3e77adfb6bb42f2



Signing certificate...
root@pelican:~/source/gnutls-2.10.3# !526
/root/source/gnutls-2.10.3/src/certtool --generate-request --load-privkey /etc/ssl/gnutls/pelican.layer-7.net.key --template /etc/ssl/gnutls/pelican.layer-7.net.info --outfile /etc/ssl/gnutls/pelican.layer-7.net.req
Generating a PKCS #10 certificate request...
root@pelican:~/source/gnutls-2.10.3# !527
/root/source/gnutls-2.10.3/src/certtool --generate-certificate  --load-ca-privkey /etc/ssl/gnutls/ca.key --load-ca-certificate /etc/ssl/gnutls/ca.pem --load-request /etc/ssl/gnutls/pelican.layer-7.net.req  --outfile /etc/ssl/gnutls/pelican.layer-7.net.pem
Generating a signed certificate...
Enter the certificate's serial number in decimal (default: 1291548572):


Activation/Expiration time.
The certificate will expire in (days): 365


Extensions.
Do you want to honour the extensions from the request? (y/N):
Does the certificate belong to an authority? (y/N):
Is this a TLS web client certificate? (y/N):
Is this also a TLS web server certificate? (y/N):
Enter the e-mail of the subject of the certificate:
Will the certificate be used for signing (required for TLS)? (y/N):
Will the certificate be used for encryption (not required for TLS)? (y/N):
X.509 Certificate Information:
Version: 3
Serial Number (hex): 4cfb779c
Validity:
Not Before: Sun Dec 05 11:29:34 UTC 2010
Not After: Mon Dec 05 11:29:36 UTC 2011
Subject: C=DE,O=Layer-7 Technologies,OU=TLS Security #2,L=Erlangen,ST=Bavaria,CN=pelican.layer-7.net
Subject Public Key Algorithm: RSA
Modulus (bits 1024):
ad:4a:27:f5:cb:08:cd:88:83:8e:b3:70:e6:7f:7a:17
e9:76:ba:4d:10:f8:18:4f:e4:18:a9:ca:28:d5:ad:88
da:27:e5:30:c2:8e:c9:ec:cf:b6:a5:aa:e6:b2:48:44
6d:02:bf:64:ac:c2:b1:3f:4b:96:a4:cc:fd:bf:03:80
64:84:0e:c8:a2:4d:eb:25:6c:85:29:1f:ad:1e:e5:b2
67:66:33:8a:b2:1e:04:dd:46:72:ab:fa:03:03:d1:73
65:0a:46:52:5a:2a:25:5f:af:c9:98:89:79:51:72:30
f9:05:8a:2f:d6:35:14:54:2d:75:ab:1d:c2:51:05:a1
Exponent (bits 24):
01:00:01
Extensions:
Basic Constraints (critical):
Certificate Authority (CA): FALSE
Subject Key Identifier (not critical):
d948ffb1650d20eeabde636bff5c41e3d3b1f5fc
Authority Key Identifier (not critical):
8d07623adb759d8e6bb26bf7f3e77adfb6bb42f2
Other Information:
Public Key Id:
d948ffb1650d20eeabde636bff5c41e3d3b1f5fc

Is the above information ok? (Y/N): y


Signing certificate...

I changed the template files to be certain to be able to distinguish the certificates, once they are displayed...

Michael Rommel <mr2147>
Sun 05 Dec 2010 10:20:12 AM UTC, comment #7: 

Could you try the attached patch, on whether generates certificates that are accepted by the devices?

(file #22126)

Nikos Mavrogiannopoulos <nmav>
Group administrator
Sun 05 Dec 2010 10:09:03 AM UTC, comment #6: 

Ah, sorry I only read the description and left with the impression that only the openssl was there. I've checked the certificates and they are exactly the same except of one thing. The "signature" field of the certificate in certtool which is an AlgorithmIdentifier does not include the parameters option, since there are no parameters, while the openssl certificate includes the NULL encoding. Both are correct, but it seems that client is picky. I'll try to check if there is an easy patch to generate a key that will use NULL encoding to try.

Nikos Mavrogiannopoulos <nmav>
Group administrator
Sun 05 Dec 2010 10:05:47 AM UTC, comment #5: 

To comment #2:

Sorry, I may have been not exact: creation of the certificate without the request step does work and produce a certificate, but the issue that I reported occurs also with this certificate.

The table has been lost during reformatting in proportional font. I'll attach a picture.

I tried to use different combinations of used ca.pem certificate to sign the request files using both tools.

To comment #3:

At first I tried the recommended PKIX extensions defined in RFC5280 for the pelican certificate which should be used for TLS sessions.

If I understand the RFC correct, Key usage should be flagged as digitalSignature, keyEncipherment or keyAgreement, as stated in 4.2.1.12. Hopefully, the related certtool template keywords are: encryption_key and signing_key.

Extended Key Usage should be id-kp-serverAuth and id-kp-clientAuth. certtool template keywords: tls_www_client and tls_www_server. The client is needed, so that the postfix mail server can authenticate to the upstream mail relay.

I have tried including these options to no success. So therefore I have stripped down Key Usage and Extended Key usage and use them only in the CA certificate to avoid further complication. I configured the openssl CA config file, so that the resulting x509 output showed only minimal differences between the certs created by certtool and openssl ca.

If you have further questions, go ahead. I can also try out commands to further narrow down the issue.



Michael Rommel <mr2147>
Sun 05 Dec 2010 09:37:31 AM UTC, comment #4: 

Nikos wrote

> Could you post the gnutls certificate that has issues and the
> openssl certificate that works?


Afaiui this has already been done, see pelican.layer-7.net.pem_gtls_req_gtls_ca_openssl and pelican.layer-7.net.pem_gtls_req_gtls_ca_certtool in the attached tarfile.

Andreas Metzler <ametzler>
Sun 05 Dec 2010 09:18:39 AM UTC, comment #3: 

There are many options to enable in a certificate when generating it. It might be an option (PKIX extension) in the certificate of gnutls that frustrates the clients you use. Could you post the gnutls certificate that has issues and the openssl certificate that works? Have you tried different combinations of options when generating the certificate?

Nikos Mavrogiannopoulos <nmav>
Group administrator
Sun 05 Dec 2010 09:16:31 AM UTC, comment #2: 

<i>generating certs directly without the request step doesn't work too. In fact I tried various combinations over the course of 7 hours, see table</i>

You report two issues here. What is your issue in generating certificates without the request step? What commands do you use? Could you elaborate?

Nikos Mavrogiannopoulos <nmav>
Group administrator
Sat 04 Dec 2010 10:58:27 PM UTC, comment #1: 
Anonymous
Sat 04 Dec 2010 09:07:35 PM UTC, original submission:  

Setup:
iPhone/iPad shall send mails through TLS encrypted channel to postfix.
postfix is set up to authenticate clients either by username/password SASL or by certificate authentication. Therefore postfix/main.cf includes:

# TLS parameters
smtpd_use_tls=yes
smtpd_tls_CAfile = /etc/ssl/gnutls/ca.pem
smtpd_tls_cert_file=/etc/ssl/gnutls/pelican.layer-7.net.pem
smtpd_tls_key_file=/etc/ssl/gnutls/pelican.layer-7.net.key
smtpd_tls_ask_ccert = yes
smtpd_tls_loglevel = 2
smtpd_tls_received_header = yes

The following files are generated by certtool: ca.key, ca.pem, pelican.layer-7.net.key, pelican.layer-7.net.req

If the resulting pelican.layer-7.net.pem certificate is generated by certtool:

/root/source/gnutls-2.10.3/src/certtool --generate-certificate  --load-ca-privkey /etc/ssl/gnutls/ca.key --load-ca-certificate /etc/ssl/gnutls/ca.pem --load-request /etc/ssl/gnutls/pelican.layer-7.net.req  --outfile /etc/ssl/gnutls/pelican.layer-7.net.pem

the iPad receives ca.pem and pelican...pem and responds with an (possibly invalid) answer, on which postfix chokes with:

Dec  4 20:56:11 pelican postfix/smtpd[7317]: connect from parrot-wlan.layer-7.net[192.168.1.137]
Dec  4 20:56:11 pelican postfix/smtpd[7317]: setting up TLS connection from parrot-wlan.layer-7.net[192.168.1.137]
Dec  4 20:56:11 pelican postfix/smtpd[7317]: parrot-wlan.layer-7.net[192.168.1.137]: TLS cipher list "ALL:+RC4:@STRENGTH:!aNULL"
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:before/accept initialization
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 read client hello B
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 write server hello A
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 write certificate A
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 write certificate request A
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 flush data
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 read client certificate A
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:SSLv3 read client key exchange A
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL3 alert write:fatal:bad record mac
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept:error in SSLv3 read certificate verify A
Dec  4 20:56:11 pelican postfix/smtpd[7317]: SSL_accept error from parrot-wlan.layer-7.net[192.168.1.137]: -1
Dec  4 20:56:11 pelican postfix/smtpd[7317]: warning: TLS library problem: 7317:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:422:
Dec  4 20:56:11 pelican postfix/smtpd[7317]: lost connection after STARTTLS from parrot-wlan.layer-7.net[192.168.1.137]
Dec  4 20:56:11 pelican postfix/smtpd[7317]: disconnect from parrot-wlan.layer-7.net[192.168.1.137]

The same setup with the certificate generated by openssl, using the same ca.key, ca.pem, pelican...req using:

openssl ca -policy policy_anything -days 365 -in gnutls/pelican.layer-7.net.req -out gnutls/pelican.layer-7.net.pem

works, so that the iPad displays the certificate for review and acceptance.

Leaving out the CAfile directive in postfix works in both cases, because the initial server hello sends only the pelican...pem cert and not the ca.pem cert. It must have something to do with the combination of the ca.pem and the pelican.layer-7.net.pem. Sending a completely different ca.pem, which has not signed the pelican...pem also works.

Using openssl s_client -starttls smtp ... works in both cases. openssl verify could not find a flaw, too.

I couldn't identify the root cause - it possibly is iOS' fault, that it generates an invalid response. But on the other hand, why does it work with openssl generated certs. I have carefully reviewed both generated certs and they look very similar. Digging down asn1parse I could only detect three additional NULL values at positions 32, 365 and 606.

I'm at a loss here.

I am just posting it here, so that you are aware, that certtool generated certs may cause trouble with Apple devices.

BTW: generating certs directly without the request step doesn't work too. In fact I tried various combinations over the course of 7 hours, see table

                                   request file generated by
                        | certtool  |    openssl   |   certtool   |  openssl |
  used CA     openssl   |   works   |     works    |     works    |   works  |
generated by  certtool  |   fails   |     works    |     works    |   works  |
                        |       certtool           |           openssl       |
                                    certificate creation using

Attached are the pem and req files and the openssl ca definition.

Cheers,

  Michael.






Michael Rommel <mr2147>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #22126:  patch.txt added by nmav (500B - text/plain - Patch to set parameters as NULL)
file #22124:  gnutls_bugreport.tar added by mr2147 (30KiB - application/x-tar)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nmav (Posted a comment)
  • -email is unavailable- added by mr2147 (Submitted the item)
  • -email is unavailable- added by mr2147
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-12-08 nmav Open/ClosedOpen Closed
        StatusIn Progress Done
    2010-12-05 nmav Attached File- Added patch.txt, #22126
    2010-12-05 mr2147 Attached File- Added Screen shot 2010-12-05 at 10.52.58 .png, #22125
    2010-12-05 ametzler Carbon-CopyRemoved 20807 -
    2010-12-05 nmav StatusNone In Progress
        Assigned toNone nmav
    2010-12-04 mr2147 Attached File- Added gnutls_bugreport.tar, #22124
        Carbon-Copy- Added mr2147

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code