Tag Info

Hot answers tagged

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 ...


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 ...


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 ...


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.


4

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


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


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 ...


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.


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

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 ...


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 ...


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 ...


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

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 ...


2

First off, verify that you can connect from your local machine... you can just telnet to port 443, both on localhost (127.0.0.1) as well as on your machine's IP address. You should at least get an answer (ie. verification that there is a listener on that port). Example - This is what you do not want: $ telnet 127.0.0.1 443 Trying 127.0.0.1... telnet: ...


2

It will not be deleted because the certificate is on your server but it will be known that it expired and browsers will react appropriately, an unsecured site.


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 ...


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 ...


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.


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

Do you also have SSL 2.0 enabled? According to http://support.microsoft.com/en-us/kb/2851628 "SSL 2.0 and TLS 1.2 are not compatible with each other in Windows 7 and later operating systems. To use client-side certificates to establish an HTTPS connection over TLS 1.2, you must disable SSL 2.0".


1

Either you or the CA had to create a private/public key pair, before the CA signed the public key. You need the private key in order to decrypt the TLS traffic. If you created the key pair, then you have the private key file. If the CA created it, then they have it and you need to get it from them.


1

You've got Yourself a SSL certificate for your domain, I think you have exported certificate without private key. A ".cert" (or ".cer" or ".crt") file usually contains a single certificate, alone and without any wrapping (no private key, no password protection, just the certificate). Ex- Some CAs store the certificate's private key in a Private Key (.pvk) ...


1

I see two things immediately wrong. You have a certificate for *.example.com, but you're accessing the site as https://example.com. A wildcard certificate won't be accepted for a parent domain. Either access it via https://www.example.com, or make a new certificate. You're using a SHA1 hash for the cert. This is considered bad. the -sha256 switch in ...


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.


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.


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

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.


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 ...



Only top voted, non community-wiki answers of a minimum length are eligible