You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of #623, I took a look at the changes proposed by @localheinz. All sites I checked so far seem to be working correctly with HTTPS, and the certificates seem to be either automated with Letsencrypt, or as it the case for the main *.php.net certificate, is issued yearly by Global Sign.
Copying my comment in the linked PR above:
As far as I can see, php.net sites such as {pecl|pear|windows|gtk|conf|qa|bugs|news|wiki}.php.net use the same HTTPS certificate with CN *.php.net, so I assume they are safe to use with HTTPS without a doubt because any issues with this certificate will alert pretty much everyone.
Looking at {windows|downloads}.php.net certificates on crt.sh, they seem to be automated, so they are safe to use too.
{bk2|monitoring|prototype-meta}.php.net seem to be automated too, but I have never had any insight into who and how these sites run. Again, the crt.sh data shows the certificates are being renewed correctly.
I'd like to see if we can come to a consensus on if we can serve all *.php.net sites with an HSTS header, so browsers remember and trust (TOFU) the PHP sites to always use HTTPS, even if a user clicks a plain HTTP link, loads a resource on any php.net site, etc. Further, we can preload*.php.net as HSTS to browsers. GitHub, for example, serves all of its *.github.com sites with HSTS, and preloads them as well.
The text was updated successfully, but these errors were encountered:
623, I t
ook a look a
t the changes pr
oposed by @localhe
inz. All sites I checked
so far s
eem to be work
ing correctly with HTTPS, and the certificates s
eem to b
e either automated with Letsencrypt, or as it the case
for the main *.php.n
et certificate, is i
ssued y
early by GlobalSign.
C
opying my co
mmen
t in the link
ed PR above:
As far as I can s
ee, php.net s
ites such as {
pecl|
pear|windows
|gtk|conf|qa|bugs|
news|wiki}.php.net use
the same HTTPS ce
rtificate with CN *.php.net, so
I assume they are safe to use with HTTPS without a doubt because any issues with th
is certificate will alert pretty much every
one.
L
ooking at
{windows
|downloads
}.php.net certificates
on crt.sh, they s
eem to be aut
omated, so they are safe to use too.
{
bk
2|monitoring
|prototype-meta
}.php.net s
eem to be automated t
oo, but I have never had any insigh
t int
o who and how the
se sites run. Again,
the crt.sh data shows the certificates are being r
enewed correctly.
I'd like t
o see if we can c
ome to a consen
su
s on if we c
an serve all *.php.net sites with
an HSTS header, so browse
rs remember and tr
ust (
TO
FU
) the
PHP sites to always use
HTTPS, even if a user clicks a plain
HTTP link, loads a resource on any
php.net sit
e, etc. Further, we can prel
oad *.php.net as HSTS to browsers. GitHub, for example, serves all of its *.github.com si
tes w
ith H
STS, and preloads them as well. 1 👍🏻
As part of #623, I took a look at the changes proposed by @localheinz. All sites I checked so far seem to be working correctly with HTTPS, and the certificates seem to be either automated with Letsencrypt, or as it the case for the main
*.php.net
certificate, is issued yearly by Global Sign.Copying my comment in the linked PR above:
I'd like to see if we can come to a consensus on if we can serve all
*.php.net
sites with an HSTS header, so browsers remember and trust (TOFU) the PHP sites to always use HTTPS, even if a user clicks a plain HTTP link, loads a resource on any php.net site, etc. Further, we can preload*.php.net
as HSTS to browsers. GitHub, for example, serves all of its*.github.com
sites with HSTS, and preloads them as well.The text was updated successfully, but these errors were encountered: