<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Captive portal  for https traffic without SSL decryption in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/captive-portal-for-https-traffic-without-ssl-decryption/m-p/374749#M89111</link>
    <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/24977"&gt;@Carracido&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;You need to decrypt the traffic to effectively redirect to the captive portal correctly. If office politics aren't allowing you to setup decryption, you could potentially just setup a decryption rule for unknown users. This would allow the captive portal to be fed to the user correctly when visiting HTTPS sites while still NOT decrypting traffic as long as the user is identified. That might be an acceptable compromise to get things working correctly and still meet requirements to not decrypt traffic?&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Wed, 16 Dec 2020 18:02:07 GMT</pubDate>
    <dc:creator>BPry</dc:creator>
    <dc:date>2020-12-16T18:02:07Z</dc:date>
    <item>
      <title>Captive portal  for https traffic without SSL decryption</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/captive-portal-for-https-traffic-without-ssl-decryption/m-p/374713#M89106</link>
      <description>&lt;P&gt;Dear community,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I´m currently facing this challengue:&lt;/P&gt;&lt;P&gt;Do you know whether it´s possible to have captive portal working for https traffic without using SSL decryption?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;This requirement is not clear in the admin guide but I understand it is according the the article below:&lt;/P&gt;&lt;P&gt;&lt;A href="https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClevCAC" target="_blank"&gt;https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClevCAC&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Due to some internal policies deploying SSL decryption wouldn´t be feasible so I´d really appreciate your answers on this topic.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thank you!&lt;/P&gt;</description>
      <pubDate>Wed, 16 Dec 2020 15:26:34 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/captive-portal-for-https-traffic-without-ssl-decryption/m-p/374713#M89106</guid>
      <dc:creator>Carracido</dc:creator>
      <dc:date>2020-12-16T15:26:34Z</dc:date>
    </item>
    <item>
      <title>Re: Captive portal  for https traffic without SSL decryption</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/captive-portal-for-https-traffic-without-ssl-decryption/m-p/374749#M89111</link>
      <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/24977"&gt;@Carracido&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;You need to decrypt the traffic to effectively redirect to the captive portal correctly. If office politics aren't allowing you to setup decryption, you could potentially just setup a decryption rule for unknown users. This would allow the captive portal to be fed to the user correctly when visiting HTTPS sites while still NOT decrypting traffic as long as the user is identified. That might be an acceptable compromise to get things working correctly and still meet requirements to not decrypt traffic?&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 16 Dec 2020 18:02:07 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/captive-portal-for-https-traffic-without-ssl-decryption/m-p/374749#M89111</guid>
      <dc:creator>BPry</dc:creator>
      <dc:date>2020-12-16T18:02:07Z</dc:date>
    </item>
  </channel>
</rss>

