Your message dated Thu, 15 Feb 2018 11:22:33 +0200
with message-id <SWEDEN7027b8dab38d470f834c4d3dad5dde88@SWEDEN>
and subject line Direktoriaus kontaktai - tai Jūsų klientas
has caused the Debian Bug report #737921,
regarding [TLS1.2] gnutls only likes SHA1 and SHA256 certificates
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
737921: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: gnutls26
Version: 2.12.23-10
Severity: minor
Dear GnuTLS maintainers,
I've just spent several hours debugging a problem which I think should be
stated somewhere. (Severity minor as it's a documentation issue.)
After replacing some expired certificates, I wondered why satellite exim4
instances would no longer talk to the one that had just received a new
certificate. With s_client and gnutls-cli-debug I could narrow the problem
down to a problem with TLS1.2 - albeit the reason was completely opaque.
The only output on the server side was the infamous
] (gnutls_handshake): Could not negotiate a supported cipher suite.
After single-stepping through exim and hotpatching _gnutls_log_level and
_gnutls_log_func to meaningful values I found that the library was
removing all the ciphers, accompanied by another, even more cryptic
message about the server certificate:
] Feb 6 23:19:58 $HOST exim4: ASSERT: gnutls_handshake.c:3348
] Feb 6 23:19:58 $HOST exim4: Could not find an appropriate certificate:
Insufficient credentials for that request.
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_DSS_ARCFOUR_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_DSS_3DES_EDE_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_DSS_AES_128_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_DSS_AES_256_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_DSS_CAMELLIA_128_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_DSS_CAMELLIA_256_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_DSS_AES_128_CBC_SHA256
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_DSS_AES_256_CBC_SHA256
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_RSA_3DES_EDE_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_RSA_AES_128_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_RSA_AES_256_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_RSA_CAMELLIA_128_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_RSA_CAMELLIA_256_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_RSA_AES_128_CBC_SHA256
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
DHE_RSA_AES_256_CBC_SHA256
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
RSA_ARCFOUR_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
RSA_ARCFOUR_MD5
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
RSA_3DES_EDE_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
RSA_AES_128_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
RSA_AES_256_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
RSA_CAMELLIA_128_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
RSA_CAMELLIA_256_CBC_SHA1
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
RSA_AES_128_CBC_SHA256
] Feb 6 23:19:58 $HOST exim4: HSK[0x7fe9524e2680]: Removing ciphersuite:
RSA_AES_256_CBC_SHA256
] Feb 6 23:19:58 $HOST exim4: ASSERT: gnutls_handshake.c:921
] Feb 6 23:19:58 $HOST exim4: ASSERT: gnutls_handshake.c:586
] Feb 6 23:19:58 $HOST exim4: ASSERT: gnutls_handshake.c:2358
] Feb 6 23:19:58 $HOST exim4: ASSERT: gnutls_handshake.c:2991
$SEARCHING revealed that I might have set improper keyUsage extensions on the
certificate - however there were none, and as I generated another certificate
with explicit keyUsage just to check, sure enough the problem persisted.
So another round of digging into GnuTLS source code, until I finally
stumbled across this gem:
] int
] _gnutls_server_select_cert (gnutls_session_t session,
] gnutls_pk_algorithm_t requested_algo)
] {
] [...]
] for (i = 0; i < cred->ncerts; i++)
] {
] /* find one compatible certificate
] */
] if (requested_algo == GNUTLS_PK_ANY ||
] requested_algo == cred->cert_list[i][0].subject_pk_algorithm)
] {
] /* if cert type and signature algorithm matches
] */
] /* *INDENT-OFF* */
] if (session->security_parameters.cert_type
] == cred->cert_list[i][0].cert_type
] && (cred->cert_list[i][0].cert_type == GNUTLS_CRT_OPENPGP
] || /* FIXME: make this a check for certificate
] type capabilities */
] !_gnutls_version_has_selectable_sighash
] (gnutls_protocol_get_version (session))
] ||
] _gnutls_session_sign_algo_requested
] (session, cred->cert_list[i][0].sign_algo) == 0))
] {
] idx = i;
] break;
] }
] /* *INDENT-ON* */
] }
] }
requested_algo was PK_ANY, cert_type X509, that part was uninteresting.
_gnutls_version_has_selectable_sighash() is TRUE iff we are doing TLS1.2; ah!
_gnutls_session_sign_algo_requested() looks at whether the client actually
requested a particular signature algorithm to go with that connection; of
course it didn't. So we fall back to an "agreeable default":
] /* extension not received allow SHA1 and SHA256 */
] hash = _gnutls_sign_get_hash_algorithm (sig);
] if (hash == GNUTLS_DIG_SHA1 || hash == GNUTLS_DIG_SHA256)
] return 0;
Better not be an early adopter and create certificates with SHA512...
downgraded the certificate's hash algorithm, and it works flawlessly again.
This error message "Insufficient credentials for that request" *really* has
to go away or to be replaced with something more meaningful. Calling this
"misleading" is still euphemistic...
Jan
--- End Message ---
--- Begin Message ---
Laba diena,
Noriu Jus informuoti apie šių metų pasikeitimą dėl atnaujintos visos Lietuvos
įmonių bazės 2018 metų sausio vidurio.
Visi juridiniai asmenys pateikti bazėje yra veikiantys, realiai vykdantys
veiklą, turintys įdarbintų darbuotojų. Duomenys pagal Sodrą, Registrų centrą.
Bazėje nurodoma ir apyvarta, darbuotojų atlyginimai, darbuotojų skaičius,
transporto skaičius ir daug kitų duomenų, kuriuos matysite pavyzdyje.
Duomenis galima filtruoti pagal veiklas, miestus ir kitus duomenis.
Šią bazę verta turėti visoms įmonėms. Pateiksiu priežastis:
1) Kontaktai pateikti bazėje direktorių ir kitų atsakingų asmenų, didelė
tikimybė Jums surasti naujų klientų, partnerių, tiekėjų, kai tiesiogiai
bendrausite su direktoriais, komercijos vadovais.
2) Konkurentų analizavimas, tiekėjų atsirinkimas pagal Jums reikalingus
kriterijus, galite atsifiltruoti pagal įmonės dydį, bazėje nurodoma kiek įmonės
skolingos Sodrai.
3) Lengva, greita ir patogu dirbti su šia baze, elektroninius pašto adresus
galite importuoti į elektroninių laiškų siuntimo programas ar sistemas iš kurių
siunčiate elektroninius laiškus.
Taip pat galite importuoti mobiliųjų telefonų numerius į SMS siuntimo programas.
Išsirinkite iš "Veiklų sąrašo" veiklas kurių Jums reikia.
( Sąrašas prisegtas laiške excel faile )
Parašykite, kurias veiklas išsirinkote
ir atsiųsime pavyzdį ir pasiūlymą su sąlygomis įmonių bazei įsigyti
Pagarbiai,
Tadas Giedraitis
Tel. nr. +37067881041
Veiklos.xlsx
Description: Binary data
--- End Message ---
