Tag Info

New answers tagged

0

Debian 6 (Debian Squeeze) is an old Debian version and will not include newer utilities like OpenSSL 1.0.1 & above. Utilities like OpenSSL 0.9.8 will receive security updates until February 2016. Plan your migration to Debian stable now. If you are not very experienced in compiling utilities like OpenSSL and replacing them in Apache, don't do it-- you ...


0

After posting the same question in the cURL website, I got a few answers that gave me new ideas that I tried and solved the problem, so I decided to post them here, in case someone else has similar problems: The first clue was the error codes themselves (-12195, -12271, -12268). Someone gave me a URL that explains all of them: ...


0

I figured it out! The problem was my openssl.cnf. The old certificate was created with string_mask = utf8only. This line was missing from my current file, resulting in a default value of PrintableString, T61String, BMPString. I did not use any non-ASCII characters, but it seems it was still enough to irritate Firefox.


0

I deleted the old certificate from my PC and installed the new one. Firefox uses its own separate certificate store. At the risk of stating the obvious (for those of us who regularly use Firefox), did you add the new CA certificate to Firefox itself?


0

I am not sure if you would be able to setup Nginx to log detailed errors when say SSLv3 connection is made. But you can definitely configure it to log all SSL or TLS connections and then you can parse the SSLv3 type connections. In order to do that you will need to add the '$ssl_protocol ' option to the log_format line in your nginx configuration file. In ...


0

Answered by @Ismooth (in question comment), thank you. You have a typo in your domain.com.conf listen 433 ssl; should be listen 443 ssl;


0

This is the stupidest thing, but through testing I had tried proxy_pass with https and nginx failed restart. It seems that was another problem. Solution: proxy_pass https://10.0.3.103:8080; [sigh]


3

The wireshark dump you provide is not helpful, because it only shows the information at the transport layer (TCP) and not the TLS layer. It also does not show any kind of error messages from the clients nor does it show how the clients use these proxies and how they validate the certificate. In generally a TLS connection needs to validate the servers ...


0

According to this report https://code.google.com/p/android/issues/detail?id=35050 your problem could also arise from a bug in Androids implementation of the libcore/luni/src/main/java/libcore/net/http/HttpConnection.java. Due to this bug the SNI at the TLS layer is the hostname of the proxy instead of the hostname provided in the HTTP request URL it should ...


2

After trying to find ways to debug with HAProxy I finally gave in and used tcpdump to debug the network traffic. By importing the TLS key and the PCAP file into my SSL-enabled Wireshark, I found the error very quickly: The Root CA was unknown to HAProxy, so the verify was failing. It turned out, a coworker changed the cert but didn't know this PEM needs ...


1

If you want to serve smtp/imap for subdomains then one dedicated subdomain is preferrable. IMHO you even shouldn't split your services into two or more separate subdomains like smtp.example.com and pop.example.com. Just use mail.example.com that can be used for smtp/pop/imap and even http if you plan to launch some webmail.


3

Or I should just use one domain to simplify it like mail.example.com for sending and receiving? Yes, I would advise it. In fact Google Apps using the same technique to handle the thousands domains pointing on it. Google Apps customer must setting his MX record to ASPMX.L.GOOGLE.COM (and friends). All users also use smtp.gmail.com and imap.gmail.com ...


3

Certificate validation will be done by the client. Use of wildcards is defined for POP, IMAP and SMTP, so a wildcard certificate should fit. But it might be that some older clients have problems, because the details for certificate handling in SMTP were only defined much later then for the other protocols so some old clients might not expect wildcards.


0

Yes, you can use a Name-based virtual hosting, but with some fairly strong provisos If you want to embrace the bleeding edge and don't care about support for old browsers, you can use Server Name Indication (SNI) (if supported by your web server and clients). This means that the client will inform the server (when its first starting to talk about SSL) ...


2

I would say this depends entirely on who and what is connecting to your LDAP server. Every client that connects via LDAPS SHOULD verify that the certificate is signed by a trusted authority. Not all of them do. (This is what EEAA is referring to) A self signed certificate will not be trusted by default. So it will need to be imported into the list of ...


-2

i have that establish secure connetion lag too... i look in chrome advanced parameter. scroll down to https/ssl and deleted all certificate relative to comodo (found them in the second or third tab, din't remember), never got that establish secure connection lag again hope that help


3

The reason is explained on StartCOM's forum: https://forum.startcom.org/viewtopic.php?f=15&t=15929&p=21716 And on Chrome's: https://code.google.com/p/chromium/issues/detail?id=473105 It is indeed SHA1. It's due to Windows' or Chrome's certificate cache. Because they (old and new intermediary cert) have the same name, the client will use the ...


0

Here is the problem: SSLCertificateKeyFile /etc/apache2/ssl/domain.csr You put your certificate signing request (CSR) file here by mistake. You should put there the private key file you used to generate the CSR instead. That private key file should not be password-protected, otherwise you would need to type a password every time you (re-)start Apache. ...


0

Try adding check-ssl to the server lines to force the health check to run over SSL as well.


0

Your clients don't need their own certificate. They just need to trust the Certificate Authority certificate (or certificate chain) that signed the LDAP server's certificate. You didn't need to worry about this on the localhost because the CA certificate was already trusted by default. It's not clear from your question whether the LDAP server is also the ...


4

I believe this might have to do with the deprecation of SHA-1. Early this year, Google made a change on its Chrome 41 browser.Accordingly, 'sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA1-based signature as part of the certificate chain, will be treated as “affirmatively insecure” '. Trusted root ...


0

Sorry, would have added as a comment but not enough rep. See here: http://security.stackexchange.com/questions/52834/what-exactly-does-it-mean-when-chrome-reports-a-certificate-does-not-have-publi


0

Just make sure that you use a higher version of Java than 7u75 (it disables them by default) then I think enabling TLS1.0 only can cause the downgrade for SSLv3 then you could use -Dweblogic.security.SSL.protocolVersion=TLS1 and TLS1.1. You should have disabled CBC a long time ago https://community.qualys.com/thread/9974. So you might have conflicting ...


1

Regarding your problem the answer is here: https://forum.startcom.org/viewtopic.php?p=21511 But your site looks ok on my chrome browser with the same version: You should clear the cache? Clearning Chrome SSL cache? https://productforums.google.com/forum/#!topic/chrome/z3biAPhNVDw


1

The reseller pre-purchases thousands of them at once. Additionally, the issuing CA use the resellers to do what's called "Market Segmentation". In other words, there are people who are happy to pay $49/cert and those that are happy to pay $490/cert and those that only want to pay $4.95/cert. By selling the certs at a really low price, they capture all the ...


5

Your certificate is using the outdated SHA-1 algorithm, which because of security risks Google Chrome now warns about. http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know https://shaaaaaaaaaaaaa.com/check/aws.hatchlings.com ...


2

Without seeing the configs you have specified, I'm going to make an educated guess. In a non-SSL HTTP request, nginx knows what virtual server configuration you are requesting based on the HTTP Host: header that your browser sends. If you send a Host: header that doesn't match any of your virtual configurations, the server will send you to the default ...


1

It is a MTU issue, this iptable rule(on gateway box) make it work: iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu


1

I would put them in a separate class, e.g. "wildcard_ssl_", and probably include that from both of 'webappX' classes, or maybe from both profiles instead.


0

You might be able to get away with: $SERVER["socket"] == "[::]:80" { } ssl.engine = "enable" ssl.ca-file = "/etc/lighttpd/ssl/startcom.ca.pem" ssl.pemfile = "/etc/lighttpd/ssl/www.unixforces.net.pem" from http://utcc.utoronto.ca/~cks/space/blog/linux/LighttpdIpv6


1

Actually to avoid configuring the SSL bits for all the hosts you could edit the mods-enabled/ssl.conf file. Any changes you make here should be used for all sites where you enable SSL as long as you just specify SSLEngine on for all sites


1

I don't see the point on connecting to the node/beego with HTTPS. Just try: Customers ---> HTTPS-Apache ---> HTTP-node Take in mind node is singlethreaded, so you should not use it on intensive CPU (and SSL it is) otherwise request will be queued.


4

The desktop subdomain doesnt seem to be setup in DNS. Nor is backend. You need to set A records for those subdomains in your DNS, which appears to be ultradns.net


0

Depending on your urgency you could wait for adoption of "Salsa20" and "ChaCha" in particular that is intended to be direct replacement for RC4 in terms of performance. However, right now only google Chrome and latest releases of Android OS support it on the client side and it is not in OpenSSL yet, so no servers support yet. Otherwise I agree with others on ...


0

Everything what do you need to setup - it's your case nginx as reverse proxy for zope: http://wiki.zenoss.org/Newsletter:5/Encrypt_All_the_Bits


2

A few things to clear up, first. We are mixing two different concepts a bit: the protocol and cipher suites. SSLv3 being the protocol, and forward secrecy being a trait of the negotiated cipher suite. Which cipher suites are selected depends on the client, the server, and the protocol that gets negotiated. This means you cannot rely on the version of the ...


1

You don't need those setting in both places. For a single site, it doesn't particularly matter which one you use, and there's no performance difference. In multi-site configurations, it matters very much. For example, if you have two sites a.example.com and b.example.com, a single wildcard *.example.com certificate defined at the site level would be ...


0

The SSL definition entries can be inside a VirtualHost to give a certificate just for theat VirtualHost. This of course becomes useful when you want to serve more than one site with SSL and they have different certificates. The config can also have a default SSL Certificate that it uses for any VirtualHost that does not explicitly specify a certificate.


2

To debug the situation you can use the command line tools of openssl, especially openssl s_client. By adding the options -tls1, -tls1_1 and -tls1_2 you can test compatibility for the protocols, and with -cipher [cipherlist] for ciphers. For example openssl s_client -connect example.com:443 -tls1 You will get detailed information and possibly warnings ...


0

I'm sure this won't get you all the way across the finish line, but without this I don't think you'll get an A+: SSLHonorCipherOrder on This keeps the browser's cipher order preferences from overriding what you've configured.


0

I am actually using this strong suite: SSLCipherSuite ...


1

The following should work for you: cp /etc/ssl/openssl.cnf /tmp echo '[ subject_alt_name ]' >> /tmp/openssl.cnf echo 'subjectAltName = DNS:www.example.com, DNS:site1.example.com, DNS:site2.example.com' >> /tmp/openssl.cnf openssl req -x509 -nodes -newkey rsa:2048 \ -config /tmp/openssl.cnf \ -extensions subject_alt_name \ -keyout ...


1

Agree with @Greg. Those attacks are possible. However the MTAs can be configured(depending on the MTA) to use "mandatory TLS", not "opportunistic TLS". What this means is that TLS and only TLS is used(this also includes STARTTLS) for the email transactions. If the remote MTA doesn't support STARTTLS, the email is bounced.


0

for newer Tomcats use sslProtocols and sslEnabledProtocols combo like this: <Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocols="TLSv1,TLSv1.1,TLSv1.2" ...


0

Your listed third option is when clientsite1 is accessed via https. The certificate error is because your SSL certificate is (only) for clientsite2. Here are your options: You want clientsite1 to be accessible via SSL, via a single IP You need a multidomain SSL certificate that has both clientsite1 and clientsite2 listed. Your SSL vHost configuration ...


0

If, like me, you found this answer but were looking for the dynamic config (cn=config) option, use the following ldif. dn: cn=config changetype: modify replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /path/to/host.key - replace: olcTLSCertificateFile olcTLSCertificateFile: /path/to/host.crt - replace: olcTLSCACertificatePath ...


4

To do this, you'll need to configure an ELB that balances TCP, not HTTPS. If you do this, it will not ask you for a certificate.


7

You can run the following tests: telnet $server_ip 443 this will tell you if there is something listening in that port telnet desktop.just4bettors.mobi 443 Trying xxx.xxx.xx.xxx... Connected to desktop.just4bettors.mobi. Escape character is '^]'. ^] telnet> q Connection closed. openssl s_client -connect $server_ip:443 -showcerts this will actually ...


4

You can pass your domain on https://www.ssllabs.com/ssltest/ it will test your sll and send back detailed result. like bellow:


0

I think there is a mistake in your backend config. Try instead: frontend https_frontend bind *:443 ssl crt /etc/ssl/certs/ourpublicandprivatecert.pem mode http default_backend web_server backend web_server mode http server s1 10.0.1.4:80 check The changing being the port! And also make sure that your webserver is not redirecting from port 80 to ...



Top 50 recent answers are included