Some issues with email certificates and Android 4.4.2 KitKat

My domain is:
My web server is (include version): Apache2, 2.4.10-10+deb8u8
The operating system my web server runs on is (include version): Debian GNU/Linux 8.5 (jessie)

Hi friends,
I’ve just (for more than 70 hours) migrate the domain “” on my server,
request the new (SHA-256) Letsencrypt certificate using the “expand” plugin, reload the servers, etc…
Now all seem to works fine, but yesterday I’ve found a strange behavior on an android 4.4.2 KitKat smartphone.
In fact for this phone trying to configure email with the “google email app” client, and setting up access to the pop3 server either ssl/tls and starttls I always got the error:

The certificate has a lower level of security than google standards

And no way forward

So I’ve try with other clients, opensource too, as “K-9 Mail” but nothing, the error was the same.

I tried on another android CyanogenMod 12 (Android 5.1.1) device with its default client and no one problem.

So, returning to the previous Samsung Grand Neo device, I set on Google Email app the IMAP mode (instead of the pop3) and for now it seem to have no problems.

What could have been? :grimacing:

Many thanks!

I suggest you try scanning it with this tool and fix the stuff it reports: Don’t forget to include the port when you scan it, otherwise it will just scan port 443, which is not what you want. You seem to be quite confused about the problem, as you mention your Apache version, but POP3/IMAP is handled by a completely different program (Dovecot on your server). I suggest that you look at the Dovecot section of for a start.

1 Like

Ah, very interesting tool!

Oh, gosh! I am well aware that it is not Apache to manage POP and IMAP traffic, just that today when I wrote the heat probably gave me to the head! :sweat_smile:

Thanks again

I’ve tested some (Postfix 2.11.3-1 ports),
for the 110 for example the report says as “Non-compliant with PCI DSS requirements”:

TLSv1.2, TLSv1.1 and TLSv1.0:


And Non-compliant with HIPAA guidance:

TLSv1.2, TLSv1.1 and TLSv1.0:


And the “The Diffie-Hellman parameter’s size” (Non-compliant with PCI DSS requirements)

“only 1024 bits”

Should be this the reasons of the issues?

many thanks again :slight_smile:

Do you have a screenshot of the error? Google itself doesn’t seem to find anything related to the error you’ve mentioned.

I don’t think that Google cares about the PCI DSS or HIPAA requirements, but the Diffie-Hellman parameter size is an issue as it makes the server potentially vulnerable to the LogJam attack. The link that I posted earlier explains how to fix this.

1 Like

I have no way of making a screenshot since the problem trying again is not presented.
I think it could only be a delay on updating the phone operator DNS record, since the domain was transferred from just over 70 hours, perhaps less.

Thanks for your help!

Thanks @Kitserve for yuor help!
I went to read the very very useful information that you pointed out to me.
My question now is:

the generation procedure of the “new Diffie-Hellman group” with LetsEncrytp could be the same as described on


openssl dhparam -out dhparams.pem 2048

I don’t think that it’s necessary to generate the dhparams.pem file for Dovecot. Just the ssl_dh_parameters_length = 2048 line is needed, plus setting the cipher list.

Perfect! I've added on /etc/dovecot/conf.d/10-ssl.conf

ssl_dh_parameters_length = 2048




ssl_prefer_server_ciphers = yes

Now testing dovecot from obtatain the A Final Grade!!
Your help was very targeted and effective, for me very very useful!!

Now a future problem will be solve the Diffie-Hellman issue on Postfix and this could be more complex being a public MX, but i will write to the Postfix ML about this :wink:

..and just trying to solve the issue related to Diffie-Hellman I realized that the LetsEncrypt keys are of different sizes:

The Server certificate is: RSA 4096 bits
The Intermediate CA is: RSA 2048 bits
The Root CA is: RSA 2048 bits

I had set /etc/letsencrypt/cli.ini so:


# Use a 4096 bit RSA key instead of 2048.
rsa-key-size = 4096

Why now not all the keys are on 4096 bits?

Many thanks again and I hope I have not entered too many items, possibly tell me if it is the case to create a new topic.



(Edited) Sorry, I misunderstood your question. I thought you were asking why anyone uses keys smaller than 4096 bits, but now I think you meant to ask why your setting didn’t cause all of your own keys to be 4096 bits.

Yes, my question is “why my setting didn’t cause all of my own keys to be 4096 bits”

Is it normal or I must configure differently the “cli.ini” for obtain all 4096 bits keys? And especially now that the keys exist should I follow some special procedure to ask the new ones?

Thanks again!

There were three keys listed, one for your Server, one for the Intermediate CA, and one for the root CA.

Only the first one is yours. The intermediate will almost certainly be Let’s Encrypt Authority X3, and the root will be the DST Root CA X3. These don’t belong to you, they belong to Let’s Encrypt and to Identrust (which bought the Digital Signature Trust Co)

So, your server has been given a 4096 bit key as you requested, but the others pick their own size, and there was no particular reason to choose a larger key size for the Intermediate, nor, when it was made, for the root.


Many many thanks, very clear, now I know more :wink:


…and in any case, in relation to the initially question posed, it is almost certain that it depended rather than from different phone models from different mobile phone operators and related different DNS services and different updating time of the latter. Since now the problem has not been presented.

many thanks

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.