Hi there! I see that you're having trouble accessing all Share Sites on linkit.shutterfly.com due to a TLS handshake issue. I’m here to help you get this sorted.

To make sure I understand correctly: Are you experiencing this TLS handshake error on multiple devices or just one? Also, are you accessing the sites via a web browser or an app?

Meanwhile, here are a few steps you can try to troubleshoot this on your Windows 10 device:

1. Check Your Internet Connection: Ensure your internet connection is stable. Sometimes, unstable connectivity can disrupt secure handshakes.

2. Verify Date and Time Settings: Incorrect date/time on your computer can cause SSL/TLS handshake errors.
- Right-click the date and time in the bottom-right corner of your screen.
- Select “Adjust date/time.”
- Enable “Set time automatically” and “Set time zone automatically” if not already on.

3. Clear Browser Cache and Cookies (if using a browser):
- Open your browser's settings.
- Clear browsing data including cached images and files.

4. Try a Different Browser: This can help determine if the issue is browser-specific.

5. Check for Windows Updates:
- Go to Settings > Update & Security > Windows Update and install any pending updates, especially security updates related to TLS.

6. Reset Network Settings:
- Open Command Prompt as administrator.
- Run these commands one by one:
<br> netsh winsock reset<br> netsh int ip reset<br> ipconfig /release<br> ipconfig /renew<br> ipconfig /flushdns<br>
- Restart your computer after running these.

7. Check Firewall or Antivirus Settings: Sometimes security software blocks TLS connections. Temporarily disable them to test (make sure to re-enable after).

If after these steps the problem continues, it could be an issue on the Shutterfly server side or with their TLS certificates.

Let me know if you've already tried any of these or if this issue started suddenly after a change on your device. That way, I can guide you further!

curl -v https://linkit.shutterfly.com:443 --tlsv1.3 -i

• Host linkit.shutterfly.com:443 was resolved.
• IPv6: (none)
• IPv4: 52.6.56.211, 34.199.222.45, 98.85.1.139
• Trying 52.6.56.211:443...
• schannel: disabled automatic use of client certificate
• ALPN: curl offers http/1.1
• schannel: failed to receive handshake, SSL/TLS connection failed
• closing connection #0 curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed

Thanks for sharing the curl output—it clearly shows the TLS handshake is failing with schannel on your Windows 10 system when connecting to linkit.shutterfly.com.

Since schannel is the Windows TLS provider used by curl on your system, this points to a possible issue with the TLS negotiation between your client and the server. Here’s what we can try next to isolate and potentially resolve this:

1. Test Using OpenSSL Instead of curl on Windows:
The TLS handshake debugging can be much clearer using openssl s_client. If you don’t have OpenSSL installed, you can use an online tool or install OpenSSL for Windows. Running this command:
<br> openssl s_client -connect linkit.shutterfly.com:443 -tls1_3<br>
will give you detailed handshake logs to understand exactly where it fails.

2. Check Windows TLS Settings Enablement:
- Open Internet Options (you can search "Internet Options" from the Start Menu).
- Go to the Advanced tab.
- Scroll down to the Security section and make sure that "Use TLS 1.2" and "Use TLS 1.3" are checked. If they aren't, enable them and restart your computer.
- Sometimes older protocols like TLS 1.0 or 1.1 being disabled is fine, but the newer ones must be enabled.

3. Update Windows Root Certificates:
Schannel depends on the Windows certificate store. An outdated root CA list or missing intermediate certificates can cause handshake failures. Run Windows Update fully, and also:
- Open Command Prompt as admin.
- Run: certutil -generateSSTFromWU roots.sst
- Double-click roots.sst and import any missing certificates into Trusted Root Certification Authorities.

4. Disable TLS Session Resumption and Channel Binding (Advanced):
Some misconfigurations cause handshake failure during session resumption. You can try disabling these temporarily via registry changes, but I recommend this only if comfortable or under guided support because it involves registry edits.

5. Try Disabling Antivirus/Firewall Temporarily:
Some antivirus or firewall software intercept SSL/TLS traffic and can cause handshake issues by using their own certificates or blocking connections. Temporarily disable them to test if TLS handshake succeeds.

6. Check for Server-Side Issues:
Since linkit.shutterfly.com resolves to several IPs, it's conceivable one of the server nodes is misconfigured or temporarily down. If possible, test connection at different times or from different networks.

If you’d like me to help with commands or more detailed steps on any of these, just let me know! Also, if you can test the OpenSSL command or try from another device/network and share the result, that would be really helpful.

Are you satisfied with this plan so far?

openssl s_client -connect linkit.shutterfly.com:443 -tls1_3 Connecting to 34.199.222.45 CONNECTED(00000200) 103F0000:error:0A000126:SSL routines::unexpected eof while reading:ssl\record\rec_layer_s3.c:703:

no peer certificate available

No client certificate CA names sent Negotiated TLS1.3 group: <NULL>

SSL handshake has read 0 bytes and written 1486 bytes Verification: OK

New, (NONE), Cipher is (NONE) Protocol: TLSv1.3 This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok)

103F0000:error:0A000197:SSL routines:SSL_shutdown:shutdown while in init:ssl\ssl_lib.c:2804:

Thanks for providing the OpenSSL handshake output and the context. The "unexpected EOF while reading" error in TLS 1.3 usually means the server is terminating the handshake abruptly or not completing it properly, causing the client to receive an early connection close without expected TLS records.

From recent discussions and reports (including some from OpenSSL GitHub issues), here’s what is often observed in similar cases:

- The client initiates a TLS 1.3 handshake.
- The server either doesn’t support TLS 1.3 properly or prefers to fall back to TLS 1.2 and doesn't complete the TLS 1.3 handshake.
- This leads to abrupt connection closes, triggering the "unexpected EOF" error on the client side.
- Sometimes, issues in server certificate configuration, improper ALPN (Application-Layer Protocol Negotiation), or incompatible cipher suites can cause this disconnect.

### What you can do next:

1. Try forcing TLS 1.2 instead of TLS 1.3 in your curl/OpenSSL command:
<br> openssl s_client -connect linkit.shutterfly.com:443 -tls1_2 <br>
or
<br> curl -v https://linkit.shutterfly.com:443 --tlsv1.2 -i <br>
If this works without error, it confirms the server’s TLS 1.3 implementation or support is likely problematic.

2. Test from different networks and devices:
To ensure it’s not something on your Windows machine or local network interfering, try accessing the site or running openssl commands from another device or internet connection.

3. Check for any Shutterfly Share Sites service updates or outages:
Sometimes this issue can be server-side. If Shutterfly is aware, they might be updating or fixing their TLS service. You might want to check status pages, forums, or contact their support directly.

4. Workaround in your client environment:
If you control the app making TLS connections, configure it to prefer TLS 1.2 when connecting to linkit.shutterfly.com, as that may avoid the handshake failures until the server fixes TLS 1.3 support.

From the current data, it seems this is a server-side issue with TLS 1.3 on Shutterfly's Share Sites backend. Since your Windows curl fails outright with schannel and OpenSSL reports an incomplete handshake, shifting to TLS 1.2 for now is a practical approach.

If you want me to walk you through setting up curl or your application to prefer TLS 1.2, or if you’d like me to help escalate this to Shutterfly’s technical team, just say the word!

Are you satisfied with this solution direction so far? Would you like assistance with any of these next steps?

Here is a related discussion that matches your error: TLS handshakes successful with TLS1.2 but failing with TLS1.3

openssl s_client -connect linkit.shutterfly.com:443 -tls1_2 Connecting to 34.199.222.45 CONNECTED(00000200) BC290000:error:0A000126:SSL routines::unexpected eof while reading:ssl\record\rec_layer_s3.c:703:

no peer certificate available

No client certificate CA names sent

SSL handshake has read 0 bytes and written 226 bytes Verification: OK

New, (NONE), Cipher is (NONE) Protocol: TLSv1.2 Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1773593018 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no

BC290000:error:0A000197:SSL routines:SSL_shutdown:shutdown while in init:ssl\ssl_lib.c:2804:

Thanks for the detailed info and your continued troubleshooting. The OpenSSL error "unexpected eof while reading" happens because the server is closing the connection abruptly during the TLS handshake without the proper TLS "close_notify" alert, which is against protocol expectations. In your case, both TLS 1.3 and TLS 1.2 attempts fail similarly.

From the search results and similar reported cases:

- This error often points to a server-side issue, where the server terminates the handshake abruptly rather than completing it properly or sending the expected SSL/TLS alerts1.
- It may be due to misconfiguration or temporary problems with the Shutterfly Share Sites backend TLS setup.
- Sometimes, server infrastructure changes or firewall/security appliances affecting TLS traffic can cause this behavior.

Given what you've seen, here’s what I recommend next:

1. Confirm if the issue is specific to your network or globally:
Try accessing the site or running the same OpenSSL / curl commands from a different network or device. This will help determine if it’s local or server-wide.

2. Contact Shutterfly Support with this error info:
Since this looks like a server-side TLS handshake issue on Shutterfly’s Share Sites domain, getting their engineering or network team involved is important. You can email [email protected] with your error details and the debugging commands you ran. They might be aware or need to investigate their certificates or TLS configurations.

3. Check Shutterfly Status / Updates pages:
Look for any announcements on outages or maintenance related to Share Sites. Sometimes TLS server issues happen during updates or incidents.

4. Temporary Workaround:
If you are using an app or integration that can choose protocols or API endpoints, see if there's an alternative or fallback endpoint that doesn’t experience these TLS issues until Shutterfly resolves them.

To sum up, your thorough testing indicates the TLS handshake failure is caused by abrupt server-side connection closures, an issue Shutterfly’s team would need to resolve. Local fixes like updating clients or system certs won’t fix this scenario because no certificate was presented.

Would you like me to help draft an email to Shutterfly support including your testing details? Also, I can guide you in checking for any hidden proxy/firewall in your network that might cause connection resets if you want to rule that out.

Are you satisfied with this approach so far?

Draft an email to Shutterfly support with all testing details

Certainly! Here's a clear and detailed email draft you can send to Shutterfly support ([email protected]) including all your testing details regarding the TLS handshake failures with Share Sites:

---

Subject: Urgent: TLS Handshake Failures Accessing Shutterfly Share Sites (linkit.shutterfly.com)

Dear Shutterfly Support Team,

I am writing to report connectivity issues with Shutterfly Share Sites (linkit.shutterfly.com). All requests to the domain are failing due to TLS handshake errors, and I have conducted several tests which consistently show the server abruptly terminates the TLS handshake without presenting a certificate.

Below are the detailed test results from a Windows 10 environment using curl and OpenSSL:

1. Curl test with TLS 1.3:

<br>curl -v https://linkit.shutterfly.com:443 --tlsv1.3 -i<br><br>* schannel: failed to receive handshake, SSL/TLS connection failed<br>curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed<br>

2. OpenSSL test with TLS 1.3:

<br>openssl s_client -connect linkit.shutterfly.com:443 -tls1_3<br><br>CONNECTED(...)<br>103F0000:error:0A000126:SSL routines::unexpected eof while reading:ssl\record\rec_layer_s3.c:703:<br>no peer certificate available<br>SSL handshake has read 0 bytes and written 1486 bytes<br>Verification: OK<br>...<br>

3. OpenSSL test with TLS 1.2:

<br>openssl s_client -connect linkit.shutterfly.com:443 -tls1_2<br><br>CONNECTED(...)<br>BC290000:error:0A000126:SSL routines::unexpected eof while reading:ssl\record\rec_layer_s3.c:703:<br>no peer certificate available<br>SSL handshake has read 0 bytes and written 226 bytes<br>Verification: OK<br>...<br>

Summary: Both TLS 1.2 and TLS 1.3 handshakes fail with an "unexpected EOF while reading" error, and no server certificate is presented. This strongly suggests an issue on the server side terminating the TLS handshake prematurely.

I would appreciate your engineering team investigating the TLS configuration on your Share Sites infrastructure, as these errors prevent all secure connections to the service.

Please let me know if you need any further details from my side.

Thank you very much for your assistance.

Best regards,
[Your Name]
[Your Contact Information]

---

Would you like me to help you with sending this or adding anything else?

help with sending this to shutterfly

Hi! To send content to Shutterfly using the Share Sites app (or the Shutterfly app itself), here’s a simple step-by-step guide:

1. Download the Shutterfly app from your device's app store if you haven't already.
2. Open the Shutterfly app and tap the Upload button.
3. Select the photos or content from your phone album that you want to send to Shutterfly.
4. After selecting, tap Upload.
5. Choose or identify the folder location within your Shutterfly account where you want to store the uploaded photos.
6. Confirm by clicking Upload again to complete the process.

Once uploaded, photos will show an orange box with an "S" in the lower right corner to indicate they are stored on Shutterfly.

If you want to share albums or content from Shutterfly, you can open the desired album on the website or app, click Share, and send via email or create a unique shareable link.

For more detailed instructions, you can visit this guide: How to Create a Share Website Using Shutterfly.com

Let me know if you want help with any specific step!

Common causes for no peer certificate available error

Hi! The "no peer certificate available" error during a TLS/SSL handshake typically means that the server did not present its SSL certificate to the client, which is essential for establishing a secure connection.

For the Shutterfly Share Sites app or any TLS connection, common causes for this error can include:

1. Server Misconfiguration: The Shutterfly server might be misconfigured to skip sending its SSL certificate during the handshake.

2. Server Outage or Maintenance: Temporary issues or maintenance on Shutterfly’s servers can cause incomplete TLS handshakes.

3. Network Interception or Proxy: Middleboxes (like corporate proxies, firewalls, or antivirus software) sometimes intercept or alter TLS handshakes, interfering with certificate delivery.

4. Expired or Invalid Certificates: If the server’s certificate is expired, revoked, or improperly installed, some clients may fail to receive or recognize it.

5. TLS Version or Cipher Mismatch: If client and server cannot agree on TLS protocol version or cipher suites, the server might abort before sending the certificate.

6. Incorrect Domain or SNI Issues: The client might be connecting to an IP or domain that the server does not have a certificate for, or SNI (Server Name Indication) extension might be missing, so the server does not know which certificate to present.

7. Expired Root or Intermediate Certificates on Client: If the client’s trusted root CA list is outdated or missing needed certificates, it might fail during verification or misinterpret server behavior.
<brTo address this in Shutterfly Share Sites context, the best next step is to confirm if the problem is server side by:

- Testing from different devices/networks.
- Checking Shutterfly status pages or contacting support.
- Ensuring your app or device has updated root certificates and supports required TLS versions.

If you need guidance on any specific troubleshooting steps or verifying settings on your Windows 10 device, feel free to ask! Are you satisfied with this explanation?

Are there any updates or fixes from Shutterfly for this error?

Hi! Based on the latest available information, there are no specific recent updates or bug fixes from Shutterfly directly addressing the TLS handshake or "no peer certificate available" errors with Share Sites as of now. The most recent Shutterfly Share Sites app update was back in October 2022, primarily focused on UI improvements and feature additions, not TLS or connectivity fixes4.

General troubleshooting advice from Shutterfly support includes:
- Force closing and restarting the app,
- Ensuring the app and device are updated,
- Clearing app cache and data,
- Checking network connectivity1 2.

There are no known official announcements or status updates confirming a fix for server-side TLS handshake issues reported with Share Sites recently. Given the handshake errors you’re encountering, this likely remains a server configuration issue on Shutterfly’s side that you would want to escalate directly via their support channels as we discussed earlier.

If you’d like, I can help you monitor for any new updates or assist in following up with Shutterfly support to get official confirmation on fixing these connectivity problems.

Are you satisfied with this update? Would you like help with anything else regarding this?

assist in following up with Shutterfly support to get official confirmation on fixing these connectivity problems.

Hi! I’ll help you follow up with Shutterfly support to get official confirmation on the Share Sites TLS handshake and connectivity issues. Since current Shutterfly support articles and status pages don’t mention this specific error, contacting an agent directly is the best route. Here’s what I suggest:

---

### Step 1: Contact Shutterfly Support by Phone
Shutterfly phone support is recommended for urgent troubleshooting and confirmation. They can escalate your case to engineering if needed.
- Call 877-846-5515 (available 24/7)
- Explain your detailed testing results showing TLS handshake failures with no peer certificates and abrupt connection closes.
- Ask if there is a known server-side issue or ongoing fix regarding Share Sites connectivity problems.

---

### Step 2: Email Follow-Up
If you prefer written communication or want to provide all details upfront, send the draft email we prepared earlier to:
[email protected]

Include:
- Your troubleshooting steps and curl/openssl test outputs
- Explain the TLS handshake failures and no certificates received
- Request official confirmation on any identified server-side issues or planned fixes

---

### Step 3: Keep Monitoring Official Shutterfly Resources
- Check Shutterfly Support main page occasionally for updates.
- Review their troubleshooting articles for any new tips related to Share Sites connectivity1.

---

If you want, I can help draft a concise phone script or assist you in sending the email. Just let me know! How would you like to proceed?