How to setup certs for https access for Fedora 42?

[Michael D. Setzer II]

Have been running http on port 8081 for long time with no 
problem. Tried to do similar with 8443 for https, but would never 
get connection. ISP blocks port 80 and 443 to regular home 
machine.

ISP did some changes, and I can now connect using port 8443 that 
maps to port 443 on machine. Gives security warning

Error code: SEC_ERROR_UNKNOWN_ISSUER

I can add an exception, but would have to have all users do the 
same. What is option to create the certificates.

Just have some basic web pages to share data?

+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor (Retired)     
 mailto:[e-mail]                            
 mailto:[e-mail]
 mailto:[e-mail]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[Samuel Sieb]

On 5/26/25 12:18 AM, Michael D. Setzer II via users wrote:
> Have been running http on port 8081 for long time with no
> problem. Tried to do similar with 8443 for https, but would never
> get connection. ISP blocks port 80 and 443 to regular home
> machine.
>
> ISP did some changes, and I can now connect using port 8443 that
> maps to port 443 on machine. Gives security warning
>
> Error code: SEC_ERROR_UNKNOWN_ISSUER
>
> I can add an exception, but would have to have all users do the
> same. What is option to create the certificates.
>
> Just have some basic web pages to share data?

If you want a recognized certificate, you either have to buy one or you 
can use certbot to get a free one from https://letsencrypt.org/.  You 
need to remember to renew it regularly.  I think they're valid for 3 
months at a time.  That's what I use.

Or, add the Certificates from the CA (and subCAs) to the webserver.
For testing purposes that should be enough.

From: "Samuel Sieb" <[e-mail]>
Date: Monday, 26 May 2025 at 9:23:34 am
To: "[e-mail]" <[e-mail]>
Subject: Re: How to setup certs for https access for Fedora 42?

On 5/26/25 12:18 AM, Michael D. Setzer II via users wrote:
> Have been running http on port 8081 for long time with no
> problem. Tried to do similar with 8443 for https, but would never
> get connection. ISP blocks port 80 and 443 to regular home
> machine.
>
> ISP did some changes, and I can now connect using port 8443 that
> maps to port 443 on machine. Gives security warning
>
> Error code: SEC_ERROR_UNKNOWN_ISSUER
>
> I can add an exception, but would have to have all users do the
> same. What is option to create the certificates.
>
> Just have some basic web pages to share data?

If you want a recognized certificate, you either have to buy one or you
can use certbot to get a free one from https://letsencrypt.org/.  You
need to remember to renew it regularly.  I think they're valid for 3
months at a time.  That's what I use.

--
_______________________________________________
users mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

[Samuel Sieb]

On 5/26/25 12:41 AM, J.Witvliet--- via users wrote:
> Or, add the Certificates from the CA (and subCAs) to the webserver.
> For testing purposes that should be enough.

What CA?  You need a signed certificate to avoid big browser warnings.

Either you use a external CA, a commercial or a community one,
Or you create a CA yourself, and do the signing locally.

You should not try a self-signed certificate.

From: "Samuel Sieb" <[e-mail]>
Date: Monday, 26 May 2025 at 9:52:13 am
To: "[e-mail]" <[e-mail]>
Subject: Re: How to setup certs for https access for Fedora 42?

On 5/26/25 12:41 AM, J.Witvliet--- via users wrote:
> Or, add the Certificates from the CA (and subCAs) to the webserver.
> For testing purposes that should be enough.

What CA?  You need a signed certificate to avoid big browser warnings.

--
_______________________________________________
users mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

[Patrick O'Callaghan]

On Mon, 2025-05-26 at 00:23 -0700, Samuel Sieb wrote:
> If you want a recognized certificate, you either have to buy one or you 
> can use certbot to get a free one from https://letsencrypt.org/.%C2%A0 You 
> need to remember to renew it regularly.  I think they're valid for 3 
> months at a time.  That's what I use.

IIRC it's now down to 14 days, but certbot takes care of it
automatically.

poc

[Michael D. Setzer II]

On 26 May 2025 at 10:34, J.Witvliet--- via users wrote:

To:	
Subject:	Re: How to setup certs for https access for Fedora 42?
Date sent:	Mon, 26 May 2025 10:34:07 +0000
Send reply to:	Community support for Fedora users 
From:	"J.Witvliet--- via users" 
Copies to:	[e-mail]
> Either you use a external CA, a commercial or a community one,
> Or you create a CA yourself, and do the signing locally.

Looked at Letsencrypt, but it wants to use domain with port 80, but 
my ISP blocks port 80 and 443, so run on ports 8081 and 8443.

Used Openssl to create files CSR and KEY and that goes thru OK, 
but then it says to submit them to CA, but gives no instructions.
> You should not try a self-signed certificate.
>
> From: "Samuel Sieb" 
> Date: Monday, 26 May 2025 at 9:52:13 am
> To: "[e-mail]" 
> Subject: Re: How to setup certs for https access for Fedora 42?
>
> On 5/26/25 12:41 AM, J.Witvliet--- via users wrote:
> > Or, add the Certificates from the CA (and subCAs) to the webserver.
> > For testing purposes that should be enough.
>
> What CA? You need a signed certificate to avoid big browser warnings.
>
> -- 
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u 
> niet de geadresseerde bent of dit bericht abusievelijk aan u is 
> toegezonden, wordt u verzocht dat aan de afzender te melden en het 
> bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor 
> schade, van welke aard ook, die verband houdt met risico's verbonden 
> aan het elektronisch verzenden van berichten.
>
> This message may contain information that is not intended for you. If you 
> are not the addressee or if this message was sent to you by mistake, you 
> are requested to inform the sender and delete the message. The State 
> accepts no liability for damage of any kind resulting from the risks 
> inherent in the electronic transmission of messages.

+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor (Retired)     
 mailto:[e-mail]                            
 mailto:[e-mail]
 mailto:[e-mail]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[Michael D. Setzer II]

On 26 May 2025 at 11:49, Patrick O'Callaghan wrote:

Subject:        	Re: How to setup certs for https access for Fedora 
42?
From:           	Patrick O'Callaghan 
To:             	[e-mail]
Date sent:      	Mon, 26 May 2025 11:49:40 +0100
Send reply to:  	Community support for Fedora users 
> On Mon, 2025-05-26 at 00:23 -0700, Samuel Sieb wrote:
> > If you want a recognized certificate, you either have to buy one or you 
> > can use certbot to get a free one from https://letsencrypt.org/.%C2%A0 You 
> > need to remember to renew it regularly.  I think they're valid for 3 
> > months at a time.  That's what I use.

I've got letsencrypt.org, and installed the certbot, but running it 
completely fails for me. Wants the site running on port 80, and my 
ISP blocks ports 80 and 443, so have mine running on port 8081 
for http and port 8443 for https. Tried to enter domand with :8081, 
but it comes back with invalid character.
> IIRC it's now down to 14 days, but certbot takes care of it
> automatically.
> poc
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor (Retired)     
 mailto:[e-mail]                            
 mailto:[e-mail]
 mailto:[e-mail]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[Charles Dennett]

On 5/26/25 6:49 AM, Patrick O'Callaghan wrote:
> On Mon, 2025-05-26 at 00:23 -0700, Samuel Sieb wrote:
> > If you want a recognized certificate, you either have to buy one or you
> > can use certbot to get a free one from https://letsencrypt.org/.%C2%A0 You
> > need to remember to renew it regularly.  I think they're valid for 3
> > months at a time.  That's what I use.
>
> IIRC it's now down to 14 days, but certbot takes care of it
> automatically.

I use a letsencrypt cert on my personal website.  You'll need the 
certbot package installed.  It includes a timer service that will check 
at least once a day for an an expiring cert and automatically renew it 
well before it expires.  The last one I got was at the end of April and 
is good until the end of July.  However, as Patrick said, they are 
supposedly shortening the time.  Mine actually updates the cert a month 
before it expires.

It was quite a while ago when I set it up but I found the instructions 
on line and followed them.  The installation automatically included 
adding the appropriate lines to the Apache config to use the new cert. 
I also redirect incoming connection on port 80 to port 443.  I don't 
recall if the installation added the config line for that or I did it 
myself but I suspect the installation took are of it for me.

In case you're curious the site is http://www.dennett.org.  Nothing 
exciting.  It's my genealogy website.

Charlie

[Tim]

Samuel Sieb:
> > If you want a recognized certificate, you either have to buy one or you 
> > can use certbot to get a free one from https://letsencrypt.org/.  You 
> > need to remember to renew it regularly.  I think they're valid for 3 
> > months at a time.  That's what I use.

Patrick O'Callaghan:
> IIRC it's now down to 14 days, but certbot takes care of it
> automatically.

Why so short?

[Todd Zullinger]

Patrick O'Callaghan wrote:
> On Mon, 2025-05-26 at 00:23 -0700, Samuel Sieb wrote:
> > If you want a recognized certificate, you either have to buy one or you 
> > can use certbot to get a free one from https://letsencrypt.org/.%C2%A0 You 
> > need to remember to renew it regularly.  I think they're valid for 3 
> > months at a time.  That's what I use.
>
> IIRC it's now down to 14 days, but certbot takes care of it
> automatically.

I don't believe that is the case, but would be interested in
reading any documentation which states it that.

90 days is what I understand the validity to be, and is the
length of the certs I have which were last renewed about a
month ago.

https://letsencrypt.org/docs/faq/#what-is-the-lifetime-for-let-s-encrypt-certificates-for-how-long-are-they-valid
    https://letsencrypt.org/2015/11/09/why-90-days.html

[Todd Zullinger]

Michael D. Setzer II via users wrote:
> On 26 May 2025 at 11:49, Patrick O'Callaghan wrote:
> > On Mon, 2025-05-26 at 00:23 -0700, Samuel Sieb wrote:
> > > If you want a recognized certificate, you either have to buy one or you 
> > > can use certbot to get a free one from https://letsencrypt.org/.%C2%A0 You 
> > > need to remember to renew it regularly.  I think they're valid for 3 
> > > months at a time.  That's what I use.
>
> I've got letsencrypt.org, and installed the certbot, but running it 
> completely fails for me. Wants the site running on port 80, and my 
> ISP blocks ports 80 and 443, so have mine running on port 8081 
> for http and port 8443 for https. Tried to enter domand with :8081, 
> but it comes back with invalid character.

There are alternate verification methods (aka "challenges").
A short list of the challenge types may be found here:

https://letsencrypt.org/docs/challenge-types/

That will get you some of the terminlogy so you can more
reasonably search through the documentation for how to do
one of them.

You can do it manually, once every 3 months or you can use
the DNS method.  That's best left to reading the
documentation, IMO.

It is a bit of work to bring yourself up to speed on it all,
if you're not familiar with TLS certificates nor the DNS
(and the API for modifying it at whatever provider you use),
but you can put that all off any do it manually a couple of
times until you spend the time to fully automate it.

[Patrick O'Callaghan]

On Mon, 2025-05-26 at 21:55 +0930, Tim via users wrote:
> Samuel Sieb:
> > > If you want a recognized certificate, you either have to buy one or you 
> > > can use certbot to get a free one from https://letsencrypt.org/.  You 
> > > need to remember to renew it regularly.  I think they're valid for 3 
> > > months at a time.  That's what I use.
>
> Patrick O'Callaghan:
> > IIRC it's now down to 14 days, but certbot takes care of it
> > automatically.
>
> Why so short?

I can't recall where I read that so take it with a pinch of salt. I
assumed it was to make certificate expiry more effective. This is a
related announcement that doesn't actually mention a reduced term, but
does say that reminder emails will no longer be sent by default:

https://letsencrypt.org/2025/01/22/ending-expiration-emails/

poc

[Patrick O'Callaghan]

On Mon, 2025-05-26 at 09:30 -0400, Todd Zullinger wrote:
> > IIRC it's now down to 14 days, but certbot takes care of it
> > automatically.
>
> I don't believe that is the case, but would be interested in
> reading any documentation which states it that.

I was sure I'd seen that but can't point to where.

poc

[Todd Zullinger]

Charles Dennett wrote:
> On 5/26/25 6:49 AM, Patrick O'Callaghan wrote:
> > On Mon, 2025-05-26 at 00:23 -0700, Samuel Sieb wrote:
> > > If you want a recognized certificate, you either have to buy one or you
> > > can use certbot to get a free one from https://letsencrypt.org/.%C2%A0 You
> > > need to remember to renew it regularly.  I think they're valid for 3
> > > months at a time.  That's what I use.
> >
> > IIRC it's now down to 14 days, but certbot takes care of it
> > automatically.
>
> I use a letsencrypt cert on my personal website.  You'll need the certbot
> package installed.  It includes a timer service that will check at least
> once a day for an an expiring cert and automatically renew it well before it
> expires.  The last one I got was at the end of April and is good until the
> end of July.  However, as Patrick said, they are supposedly shortening the
> time.  Mine actually updates the cert a month before it expires.

Is that in reference to the _option_ to use very short cert
lifetimes, as it announced here?

https://letsencrypt.org/2025/01/16/6-day-and-ip-certs/

If so, it looks to be entirely optional:

Our longer-lived certificates, which currently have a
    lifetime of 90 days, will continue to be available
    alongside our six-day offering. Subscribers will be able
    to opt in to short-lived certificates via a certificate
    profile mechanism being added to our ACME API.

Very few, if any, home users will have a need for such short
lifetime certificates.

Most non-home users won't need them either, if they're being
realistic about their attack surface.

If you have it all fully automated, it shouldn't hurt to use
the shorter lifetime, but for the purposes being discussed
here, it _seems_ like a moot point.

[Mike Wright]

> On 26 May 2025 at 10:34, J.Witvliet--- via users wrote:
>
> Looked at Letsencrypt, but it wants to use domain with port 80, but
> my ISP blocks port 80 and 443, so run on ports 8081 and 8443.

certbot allows these options:

--http-01-port HTTP01_PORT   Port used in the http-01 challenge. This 
only affects the port Certbot listens on. A conforming ACME server 
                             will still attempt to connect on port 80. 
(default: 80)

--https-port HTTPS_PORT      Port used to serve HTTPS. This affects 
which port Nginx will listen on after a LE certificate is 
      installed. (default: 443)

Note: letsencrypt has a web page where you can ask questions.  They are 
very responsive.

:m

[Michael D. Setzer II]

On 26 May 2025 at 7:12, Charles Dennett wrote:

Date sent:      	Mon, 26 May 2025 07:12:44 -0400
Subject:        	Re: How to setup certs for https access for Fedora 
42?
To:             	[e-mail]
From:           	Charles Dennett 
Send reply to:  	Community support for Fedora users 
> On 5/26/25 6:49 AM, Patrick O'Callaghan wrote:
> > On Mon, 2025-05-26 at 00:23 -0700, Samuel Sieb wrote:
> > > If you want a recognized certificate, you either have to buy one or you
> > > can use certbot to get a free one from https://letsencrypt.org/.%C2%A0 You
> > > need to remember to renew it regularly.  I think they're valid for 3
> > > months at a time.  That's what I use.
> >
> > IIRC it's now down to 14 days, but certbot takes care of it
> > automatically.
>
> I use a letsencrypt cert on my personal website.  You'll need the 
> certbot package installed.  It includes a timer service that will check 
> at least once a day for an an expiring cert and automatically renew it 
> well before it expires.  The last one I got was at the end of April and 
> is good until the end of July.  However, as Patrick said, they are 
> supposedly shortening the time.  Mine actually updates the cert a month 
> before it expires.
>
> It was quite a while ago when I set it up but I found the instructions 
> on line and followed them.  The installation automatically included 
> adding the appropriate lines to the Apache config to use the new cert. 
> I also redirect incoming connection on port 80 to port 443.  I don't 
> recall if the installation added the config line for that or I did it 
> myself but I suspect the installation took are of it for me.
>
> In case you're curious the site is http://www.dennett.org.  Nothing 
> exciting.  It's my genealogy website.

Getting closer, but still not having success with certbot.
Found that my ISP is no longer blocking ports 80 and 443, so have 
been able to change he server to use them.

nmap setzco.dyndns.org -Pn -p 80,443
Starting Nmap 7.92 ( https://nmap.org ) at 2025-05-27 02:35 ChST
Nmap scan report for setzco.dyndns.org (182.173.226.48)
Host is up (0.20s latency).

PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 0.29 seconds

But running certbot run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Please enter the domain name(s) you would like on your certificate 
(comma and/or space separated) (Enter 'c' to cancel): 
setzco.dyndns.org
Requesting a certificate for setzco.dyndns.org
Unable to find a virtual host listening on port 80 which is currently 
needed for Certbot to prove to the CA that you control your 
domain. Please add a virtual host for port 80.
Ask for help or search for solutions at
 https://community.letsencrypt.org. See the logfile 
/var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for 
more details.

Not clear what they mean by Virtual Host?
can now bring up page with http://setzco.dyndns.org without the 
:8081 fine.
https://setzco.dyndns.org gives a security error until I add an 
exception.

httpd.conf just has the basic http and https, so not how one is 
suppose to setup a Virtual Host. Just using /var/www/html

Thanks for all the info. Getting closer.
> Charlie
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor (Retired)     
 mailto:[e-mail]                            
 mailto:[e-mail]
 mailto:[e-mail]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[Barry]

> On 26 May 2025, at 17:45, Michael D. Setzer II via users  wrote:
>
> Not clear what they mean by Virtual Host?

It’s a web server feature.
You can have many virtual hosts on a physical host.
For example I host two web sites using httpd on my cloud VM.

Web search for httpd virtual host should find docs for setting this up.

Barry

[bruce]

if u have...
/etc/apache2/sites-available/..  there might be multiple  conf files  for
different weapp projects.  these files woul have virtual host
configurations as well as alias directives for the webapps

On Mon, May 26, 2025, 1:15 PM Barry  wrote:
> > On 26 May 2025, at 17:45, Michael D. Setzer II via users <
>
> [e-mail]> wrote:
> > Not clear what they mean by Virtual Host?
>
> It’s a web server feature.
> You can have many virtual hosts on a physical host.
> For example I host two web sites using httpd on my cloud VM.
>
> Web search for httpd virtual host should find docs for setting this up.
> Barry
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Jeffrey Walton]

On Mon, May 26, 2025 at 8:25 AM Tim via users
 wrote:
> Samuel Sieb:
> > > If you want a recognized certificate, you either have to buy one or you
> > > can use certbot to get a free one from https://letsencrypt.org/.  You
> > > need to remember to renew it regularly.  I think they're valid for 3
> > > months at a time.  That's what I use.
>
> Patrick O'Callaghan:
> > IIRC it's now down to 14 days, but certbot takes care of it
> > automatically.
>
> Why so short?

To reduce the size of Certificate Revocation List (CRL), and recover
quickly from a compromised host. Conventional wisdom is, browsers
don't download CRLs or OCSP, so a short validity closes the gap in
browser behavior.

Let's Encrypt has actually proposed a 3-day lifetime. See "Concerns
about very-short-lived certificates,"
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/_335unOyteQ/m/9sH7ozVCAQAJ.

Jeff

[Will McDonald]

On Mon, 26 May 2025 at 20:05, bruce  wrote:
> if u have...
> /etc/apache2/sites-available/..  there might be multiple  conf files  for
> different weapp projects.  these files woul have virtual host
> configurations as well as alias directives for the webapps

I think /etc/apache2 is more Debian/Ubuntu-based distros? But conceptually
you're bang-on. Looking at other/pre-existing vhost definitions to
understand them is a good idea.

Michael, are you using Apache as your webserver, or something else? If so
the relevant docs are:

https://httpd.apache.org/docs/2.4/vhosts/examples.html

And your config will live in /etc/httpd/ in the various conf
subdirectories. conf, conf.d predominantly.

And see
https://stackoverflow.com/questions/72028126/how-to-fix-cerbot-error-unable-...
for a similar problem

And
https://community.letsencrypt.org/t/unable-to-find-a-virtual-host-listening-...

[Samuel Sieb]

On 5/26/25 4:10 AM, Michael D. Setzer II via users wrote:
> On 26 May 2025 at 11:49, Patrick O'Callaghan wrote:
>
> Subject:        	Re: How to setup certs for https access for Fedora
> 42?
> From:           	Patrick O'Callaghan 
> To:             	[e-mail]
> Date sent:      	Mon, 26 May 2025 11:49:40 +0100
> Send reply to:  	Community support for Fedora users
> > On Mon, 2025-05-26 at 00:23 -0700, Samuel Sieb wrote:
> > > If you want a recognized certificate, you either have to buy one or you
> > > can use certbot to get a free one from https://letsencrypt.org/.%C2%A0 You
> > > need to remember to renew it regularly.  I think they're valid for 3
> > > months at a time.  That's what I use.
>
> I've got letsencrypt.org, and installed the certbot, but running it
> completely fails for me. Wants the site running on port 80, and my
> ISP blocks ports 80 and 443, so have mine running on port 8081
> for http and port 8443 for https. Tried to enter domand with :8081,
> but it comes back with invalid character.

It just want a number, not a colon.

[Samuel Sieb]

On 5/26/25 9:44 AM, Michael D. Setzer II via users wrote:
> But running certbot run
> Saving debug log to /var/log/letsencrypt/letsencrypt.log
> Please enter the domain name(s) you would like on your certificate
> (comma and/or space separated) (Enter 'c' to cancel):
> setzco.dyndns.org
> Requesting a certificate for setzco.dyndns.org
> Unable to find a virtual host listening on port 80 which is currently
> needed for Certbot to prove to the CA that you control your
> domain. Please add a virtual host for port 80.
> Ask for help or search for solutions at
>   https://community.letsencrypt.org. See the logfile
> /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for
> more details.
>
> Not clear what they mean by Virtual Host?
> can now bring up page with http://setzco.dyndns.org without the
> :8081 fine.
> https://setzco.dyndns.org gives a security error until I add an
> exception.
>
> httpd.conf just has the basic http and https, so not how one is
> suppose to setup a Virtual Host. Just using /var/www/html

You should be using virtual hosts with apache, but if you don't, then 
you can't use the apache plugin for certbot.  Try adding "--standalone" 
to the command.  You'll probably need to stop apache while you're doing it.

[Barry]

> On 26 May 2025, at 13:25, Tim via users  wrote:
>
> Why so short?

The public web is moving to cert having a 47 day max lifetime.
See https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-redu... that reports on change time line.

Barry

[Tim]

On Mon, 2025-05-26 at 09:53 -0400, Todd Zullinger wrote:
> If so, it looks to be entirely optional:
> Our longer-lived certificates, which currently have a
> lifetime of 90 days, will continue to be available
> alongside our six-day offering. Subscribers will be able
> to opt in to short-lived certificates via a certificate
> profile mechanism being added to our ACME API.
>
> Very few, if any, home users will have a need for such short
> lifetime certificates.
>
> Most non-home users won't need them either, if they're being
> realistic about their attack surface.
>
> If you have it all fully automated, it shouldn't hurt to use
> the shorter lifetime, but for the purposes being discussed
> here, it _seems_ like a moot point.

I'm not sure I believe in their automation ideas, at all (having read
further into their website).

If someone managed to hack into my (externally hosted) website and take
it over, it'd continue updating the certificate under their control. 
But if I had to be the one updating the certificate, it wouldn't get
automatically updated in my absence.

[Tim]

On Mon, 2025-05-26 at 15:19 -0400, Jeffrey Walton wrote:
> To reduce the size of Certificate Revocation List (CRL), and recover
> quickly from a compromised host. Conventional wisdom is, browsers
> don't download CRLs or OCSP, so a short validity closes the gap in
> browser behavior.

That's the first answer I've found that seemed logical.  I remember in
the past having to manually set browsers to check for revocation of
certificates, because they didn't.  Which seemed a rather dumb lack of
cross-checking.

Though it also seems that constantly changing something adds another
vector for some kind of screw-up.

Somewhat like the very dumb idea of making people constantly change
their passwords.

[Patrick O'Callaghan]

On Tue, 2025-05-27 at 19:59 +0930, Tim via users wrote:
> > If you have it all fully automated, it shouldn't hurt to use
> > the shorter lifetime, but for the purposes being discussed
> > here, it _seems_ like a moot point.
>
> I'm not sure I believe in their automation ideas, at all (having read
> further into their website).
>
> If someone managed to hack into my (externally hosted) website and take
> it over, it'd continue updating the certificate under their control. 
> But if I had to be the one updating the certificate, it wouldn't get
> automatically updated in my absence.

I'd say that if someone penetrates your website, you have worse
problems than certificate renewal.

poc

[Patrick O'Callaghan]

On Tue, 2025-05-27 at 20:05 +0930, Tim via users wrote:
> On Mon, 2025-05-26 at 15:19 -0400, Jeffrey Walton wrote:
> > To reduce the size of Certificate Revocation List (CRL), and recover
> > quickly from a compromised host. Conventional wisdom is, browsers
> > don't download CRLs or OCSP, so a short validity closes the gap in
> > browser behavior.
>
> That's the first answer I've found that seemed logical.  I remember in
> the past having to manually set browsers to check for revocation of
> certificates, because they didn't.  Which seemed a rather dumb lack of
> cross-checking.

They didn't check because having all browsers constantly check would be
a considerable burden on the certificate authorities. It's a basic
design weakness in the cert model.
> Though it also seems that constantly changing something adds another
> vector for some kind of screw-up.
>
> Somewhat like the very dumb idea of making people constantly change
> their passwords.

Not the same thing at all. Asking people to make up new passwords
according to arcane rules is an open invitation to having weak
passwords. Renewing certs periodically is a compromise between "never"
and "constantly".

poc

So, for hobby / home websites, certificates with a short lifespan is ok.

For anything else, a decent certificate provider should be used…

From: "Tim via users" <[e-mail]>
Date: Tuesday, 27 May 2025 at 12:36:07 pm
To: "[e-mail]" <[e-mail]>, "Community support for Fedora users" <[e-mail]>
Cc: "Tim" <[e-mail]>
Subject: Re: How to setup certs for https access for Fedora 42?

On Mon, 2025-05-26 at 15:19 -0400, Jeffrey Walton wrote:
> To reduce the size of Certificate Revocation List (CRL), and recover
> quickly from a compromised host. Conventional wisdom is, browsers
> don't download CRLs or OCSP, so a short validity closes the gap in
> browser behavior.

That's the first answer I've found that seemed logical.  I remember in
the past having to manually set browsers to check for revocation of
certificates, because they didn't.  Which seemed a rather dumb lack of
cross-checking.

Though it also seems that constantly changing something adds another
vector for some kind of screw-up.

Somewhat like the very dumb idea of making people constantly change
their passwords.

--

uname -rsvp
Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64
(yes, this is the output from uname for this PC when I posted)

Boilerplate:  All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.

--
_______________________________________________
users mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

[Greg Woods]

On Mon, May 26, 2025 at 1:19 AM Michael D. Setzer II via users <
[e-mail]> wrote:
> Error code: SEC_ERROR_UNKNOWN_ISSUER
>
> I can add an exception, but would have to have all users do the
> same. What is option to create the certificates.
>
> Just have some basic web pages to share

I have had very good luck with Caddy (caddyserver.com). I use it on
Raspberry Pi's (Raspbian), but it is also packaged for Fedora. There is a
bit of a learning curve to get it initially configured, but it's the best
solution I've found for home web service and the documentation is very
good.  It takes care of renewing the letsencrypt certificates for you, it
can handle the authentication for the parts of your site that may require
it (I use it as a front end for Home Assistant, among other tasks), and it
can listen on any ports that you configure and forward them to where the
web server is listening. I use a firewall to block all external access to
the actual web server and forward all external connections through Caddy,
which allows me to not worry about protecting the web server itself (which
doesn't even need a certificate when set up this way). Caddy can even be
the web server itself, if your content is static. It is way easier to
configure for that purpose than Apache (httpd).

--Greg

[Jeffrey Walton]

On Tue, May 27, 2025 at 6:50 AM Patrick O'Callaghan
 wrote:
> On Tue, 2025-05-27 at 20:05 +0930, Tim via users wrote:
> > On Mon, 2025-05-26 at 15:19 -0400, Jeffrey Walton wrote:
> > > To reduce the size of Certificate Revocation List (CRL), and recover
> > > quickly from a compromised host. Conventional wisdom is, browsers
> > > don't download CRLs or OCSP, so a short validity closes the gap in
> > > browser behavior.
> >
> > That's the first answer I've found that seemed logical.  I remember in
> > the past having to manually set browsers to check for revocation of
> > certificates, because they didn't.  Which seemed a rather dumb lack of
> > cross-checking.
>
> They didn't check because having all browsers constantly check would be
> a considerable burden on the certificate authorities. It's a basic
> design weakness in the cert model.

OCSP Stapling fixed the problem.
> > Though it also seems that constantly changing something adds another
> > vector for some kind of screw-up.
> >
> > Somewhat like the very dumb idea of making people constantly change
> > their passwords.
>
> Not the same thing at all. Asking people to make up new passwords
> according to arcane rules is an open invitation to having weak
> passwords. Renewing certs periodically is a compromise between "never"
> and "constantly".

Key continuity proved to be a better security property than gratuitous
key rotations based on the tasseomancer reading tea leaves.

Jeff

[Todd Zullinger]

Patrick O'Callaghan wrote:
> On Tue, 2025-05-27 at 19:59 +0930, Tim via users wrote:
> > > If you have it all fully automated, it shouldn't hurt to use
> > > the shorter lifetime, but for the purposes being discussed
> > > here, it _seems_ like a moot point.
> >
> > I'm not sure I believe in their automation ideas, at all (having read
> > further into their website).
> >
> > If someone managed to hack into my (externally hosted) website and take
> > it over, it'd continue updating the certificate under their control. 
> > But if I had to be the one updating the certificate, it wouldn't get
> > automatically updated in my absence.

If you didn't notice the system was compromised in order to
stop the automatic renewal, why would you notice it when you
manually renewed the certificate though?

The problems are a bit orthogonal.  I don't take it as a
given than doing it manually means you're any more (or less)
likely to notice a system compromise.
> I'd say that if someone penetrates your website, you have worse
> problems than certificate renewal.

Indeed.  If a server admin doesn't notice (or worse,
ignores) a system compromise, with or without automation,
they're a danger (or at least a nuisance) to the rest of the
network.

That is still a real problem, but it can't be solved by
certificate automation.  Many other issues can be though, so
in general, the plans to lower cert lifetime is a good one,
I think.

It is worth noting that the very short time Barry mentioned
the other day (47 days) is not coming into effect for
another 4 years.  It will get shorter in a couple of
increments on the way to that value and in the process,
(most) folks will adapt to using automated renewal tools.

For the moment, if anyone wants to pay a few bucks and get a
cert which is value for 398 days, that's easy to do.
Depending on how much time you want to invest in learning
and implementing one of the various methods of automation,
the cost of buying a cert versus getting one for "free"
might skew well in favor of the former.

[Peter Boy Uni]

> Am 26.05.2025 um 21:25 schrieb Will McDonald :
>
> On Mon, 26 May 2025 at 20:05, bruce  wrote:
> if u have...  
> /etc/apache2/sites-available/..  there might be multiple  conf files  for different weapp projects.  these files woul have virtual host configurations as well as alias directives for the webapps
>
> I think /etc/apache2 is more Debian/Ubuntu-based distros? But conceptually you're bang-on. Looking at other/pre-existing vhost definitions to understand them is a good idea.

If you want to have something for fedora you may go to

https://docs.fedoraproject.org/en-US/fedora-server/services/httpd-basic-setu...

rr better to

https://docs.stg.fedoraproject.org/en-US/fedora-server/services/httpd-basic-...

--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
[e-mail]

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast

[Barry]

> On 27 May 2025, at 15:29, Jeffrey Walton  wrote:
>
> OCSP Stapling fixed the problem.

Yes it did, but very few web sites would implement this solution.
Therefore the move to short cert life.

Barry

[Patrick O'Callaghan]

On Tue, 2025-05-27 at 10:28 -0400, Jeffrey Walton wrote:
> > Not the same thing at all. Asking people to make up new passwords
> > according to arcane rules is an open invitation to having weak
> > passwords. Renewing certs periodically is a compromise between "never"
> > and "constantly".
>
> Key continuity proved to be a better security property than gratuitous
> key rotations based on the tasseomancer reading tea leaves.

I'm not sure what you mean here.

poc

[Samuel Sieb]

On 5/27/25 5:10 AM, J.Witvliet--- via users wrote:
> So, for hobby / home websites, certificates with a short lifespan is ok.
>
> For anything else, a decent certificate provider should be used…

There is no problem for any site to have a short certificate lifespan 
and that is going to be required within a few years.

[George N. White III]

On Mon, May 26, 2025 at 9:25 AM Tim via users 
wrote:
> Samuel Sieb:
> > > If you want a recognized certificate, you either have to buy one or
>
> you
> > > can use certbot to get a free one from https://letsencrypt.org/.  You
> > > need to remember to renew it regularly.  I think they're valid for 3
> > > months at a time.  That's what I use.
>
> Patrick O'Callaghan:
> > IIRC it's now down to 14 days, but certbot takes care of it
> > automatically.
>
> Why so short?

One of the concerns is bad actors storing encrypted data until new methods
(quantum?) allow
them to decrypt the data.   Changing keys more often multiplies the effort
needed to get all the
data, which is a good thing.

Aren’t longer keys more effective than changing them often?
Especially as a Chinese team of researchers stated that they have broken a RSA-2048 private key?

From: "George N. White III" <[e-mail]>
Date: Wednesday, 28 May 2025 at 1:21:59 pm
To: "Community support for Fedora users" <[e-mail]>
Subject: Re: How to setup certs for https access for Fedora 42?

On Mon, May 26, 2025 at 9:25 AM Tim via users <[e-mail]> wrote:
Samuel Sieb:
> > If you want a recognized certificate, you either have to buy one or you
> > can use certbot to get a free one from https://letsencrypt.org/.  You
> > need to remember to renew it regularly.  I think they're valid for 3
> > months at a time.  That's what I use.

Patrick O'Callaghan:
> IIRC it's now down to 14 days, but certbot takes care of it
> automatically.

Why so short?

One of the concerns is bad actors storing encrypted data until new methods (quantum?) allow
them to decrypt the data.   Changing keys more often multiplies the effort needed to get all the
data, which is a good thing.

--
George N. White III

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

[Patrick O'Callaghan]

On Wed, 2025-05-28 at 11:40 +0000, J.Witvliet--- via users wrote:
> Aren’t longer keys more effective than changing them often?
> Especially as a Chinese team of researchers stated that they have broken a RSA-2048 private key?

[Please don't top-post]

Certificates expire to reduce the risk from *leaked* private keys, not
from realistic brute-force threats. Current recommendations regarding
keys are already long enough.

The Chinese claim is widely regarded as spurious.

poc

[Michael D. Setzer II]

Just to post the solution I found a lot of trial and error.

used certbot certonly to create the certificates.

Then just make changes to /etc/httpd/conf.d/ssl.conf

diff ssl.conf ssl.conf.sav 
59,60c59,60
< DocumentRoot "/var/www/html"
< ServerName setzco.dyndns.org:443
---
> #DocumentRoot "/var/www/html"
> #ServerName www.example.com:443

101c101
< SSLCertificateFile 
/etc/letsencrypt/live/setzco.dyndns.org/cert.pem
---
> SSLCertificateFile /etc/pki/tls/certs/localhost.crt

109c109
< SSLCertificateKeyFile 
/etc/letsencrypt/live/setzco.dyndns.org/privkey.pem
---
> SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

118c118
< SSLCertificateChainFile 
/etc/letsencrypt/live/setzco.dyndns.org/chain.pem
---
> #SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt

No need to setup a Virtual Host. Don't know why they don't list this 
option.

+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor (Retired)     
 mailto:[e-mail]                            
 mailto:[e-mail]
 mailto:[e-mail]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[Barry]

> On 29 May 2025, at 16:38, Michael D. Setzer II via users  wrote:
>
> No need to setup a Virtual Host. Don't know why they don't list this
> option.

My guess is because almost everyone uses VirtualHost sections.

Barry

[Todd Zullinger]

Barry wrote:
> > On 29 May 2025, at 16:38, Michael D. Setzer II via users  wrote:
> >
> > No need to setup a Virtual Host. Don't know why they don't list this
> > option.
>
> My guess is because almost everyone uses VirtualHost sections.

And chage the file there means you now have to track future
changes to it yourself rather than picking them up via the
normal package updates.

It's simply not the right way to make such changes.  It's
your system, so you're free to do it however you want, but
it's a good thing that Let's Encrypt doesn't recommend that
course of action.

[Michael D. Setzer II]

On 29 May 2025 at 18:08, Todd Zullinger wrote:

Date sent:	Thu, 29 May 2025 18:08:14 -0400
From:	Todd Zullinger 
To:	[e-mail]
Subject:	Re: How to setup certs for https access for Fedora 42?
Send reply to:	Community support for Fedora users
> Barry wrote:
> > > On 29 May 2025, at 16:38, Michael D. Setzer II via users  wrote:
> > >
> > > No need to setup a Virtual Host. Don't know why they don't list this
> > > option.
> >
> > My guess is because almost everyone uses VirtualHost sections.
>
> And chage the file there means you now have to track future
> changes to it yourself rather than picking them up via the
> normal package updates.

Don't understand this? Looked at another Fedora system that has 
httpd installed, but never setup. I also the VirtualHost options all 
commented out by default? So why would installing updates break 
things.

If that is what the default should be, then why isn't the VirtualHost 
setup as the default configuration rather than being commented 
out?

Had tried the certbot run --apache option in past, but it came up 
with unknown certificate provider message.

Know one can create many virtual host on a machine, but been 
doing simple setup going back to redhat 9, and then Fedora Core 1 
to Fedora 42 now. Had it on SCO and Unixware before that.

The changes are mostly to commented lines?
diff ssl.conf ssl.conf.sav 
59,60c59,60
< DocumentRoot "/var/www/html"
< ServerName setzco.dyndns.org:443
---
> #DocumentRoot "/var/www/html"
> #ServerName www.example.com:443

101c101
< SSLCertificateFile /etc/letsencrypt/live/setzco.dyndns.org/cert.pem
---
> SSLCertificateFile /etc/pki/tls/certs/localhost.crt

109c109
< SSLCertificateKeyFile /etc/letsencrypt/live/setzco.dyndns.org/privkey.pem
---
> SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

118c118
< SSLCertificateChainFile /etc/letsencrypt/live/setzco.dyndns.org/chain.pem
---
> #SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
> It's simply not the right way to make such changes.  It's
> your system, so you're free to do it however you want, but
> it's a good thing that Let's Encrypt doesn't recommend that
> course of action.

Perhaps will check it out on one of my other machines. Only have 
11 used webpages with some php and mariadb databases.
> -- 
> Todd

+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor (Retired)     
 mailto:[e-mail]                            
 mailto:[e-mail]
 mailto:[e-mail]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[Tim]

Barry:
> > > My guess is because almost everyone uses VirtualHost sections.

Todd Zullinger:
> > And chage the file there means you now have to track future
> > changes to it yourself rather than picking them up via the
> > normal package updates.

Michael D. Setzer II:
> Don't understand this? Looked at another Fedora system that has httpd
> installed, but never setup. I also the VirtualHost options all
> commented out by default? So why would installing updates break
> things.
> If that is what the default should be, then why isn't the VirtualHost
> setup as the default configuration rather than being commented out?
> Had tried the certbot run --apache option in past, but it came up
> with unknown certificate provider message.
> Know one can create many virtual host on a machine, but been doing
> simple setup going back to redhat 9, and then Fedora Core 1 to Fedora
> 42 now. Had it on SCO and Unixware before that.
> The changes are mostly to commented lines?

If you modify the main Apache configuration, there's every chance at
any update to Apache that you'll have to deal with changes to the
configuration file.  I'd say that's what Todd alludes to.

If you set up a virtual host, they're not interfered with by any RPM
updates to Apache.  And I think you /are/ encouraged to set up virtual
hosts, rather than use the main configuration.

And Barry would be alluding to how most people running public servers
are probably using a VirtualHost in someone else's hosting farm, far
more than people running private servers.  And far more than renting a
whole box in a server centre, anybody doing that is probably not going
to be using a freebie cert provider with limited trust (*).  So that
may explain Let's Encrypt's general purpose solution they promote.

* If you were a site that needed absolute trust with your clients, you
could be a bank, a shopping site, some security vendor, whatever, you
need a certificate that engenders confidence with your clients.  A tiny
step above self-signed certificates from a service that doesn't do
background checks, or really vet your identity, doesn't achieve that. 
My hosting service uses it, and I've never been vetted in any way
regarding the security certificate.  I'm simply a paying customer.

Virtual hosts are also hostname specific, incoming connections to that
service are managed by Apache according to the hostname they request,
rather than any and all connections being accepted.  You can shoehorn
the main config into working that way, but it's more effort.

Since I manage a few websites, it's convenient for me to have local
copies, and using VirtualHosts makes that easy for me.  I just use a
localised version of their hostname to browse them (e.g. change the
www. prefix of their domain to lan. such as lan.example.com).  It also
makes it easy for me to set up a test server to try anything out on,
without disrupting the main servers.

Which I really must do more often, lately I've made a few typing goofs
in one of the main sites and disrupted things, and being buried in 500
lines of CSS made it hard to find.  And, no, they weren't outright
errors so error-checking wouldn't find them, nor single errors so I
could simply revert the file.  I dug myself into a hole.

[Todd Zullinger]

Michael D. Setzer II via users wrote:
> On 29 May 2025 at 18:08, Todd Zullinger wrote:
> > And chage the file there means you now have to track future
> > changes to it yourself rather than picking them up via the
> > normal package updates.
>
> Don't understand this? Looked at another Fedora system that has 
> httpd installed, but never setup. I also the VirtualHost options all 
> commented out by default? So why would installing updates break 
> things.

To be fair, I didn't say it would break.  But now you won't
pick up any changes to /etc/httpd/conf.d/ssl.conf which are
shipped with future mod_ssl updates.  You'll then need to
merge in anything which is useful, which you have to review
and determine manually.

It's the same reason you should avoid editing most files
shipped by packages, and instead add your own file in a
conf.d directory.

It's less likely to leave you in a state where something is
updated in the default configuration down the road (maybe
years after you've forgotten that you edited the config) and
now httpd doesn't start because it depends on those changes.
> The changes are mostly to commented lines?

It's not really what the changes are, it's that you've
changed a file marked as %config(noreplace) by the package.
So future updates will create an ssl.conf.rpmnew which *may*
contain changes that are worth integrating.
> diff ssl.conf ssl.conf.sav 
> 59,60c59,60
> < DocumentRoot "/var/www/html"
> < ServerName setzco.dyndns.org:443
> > #DocumentRoot "/var/www/html"
> > #ServerName www.example.com:443
>
> 101c101
> < SSLCertificateFile /etc/letsencrypt/live/setzco.dyndns.org/cert.pem
> > SSLCertificateFile /etc/pki/tls/certs/localhost.crt
>
> 109c109
> < SSLCertificateKeyFile /etc/letsencrypt/live/setzco.dyndns.org/privkey.pem
> > SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
>
> 118c118
> < SSLCertificateChainFile /etc/letsencrypt/live/setzco.dyndns.org/chain.pem
> > #SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt

BTW, swapping the order of the arguments to diff makes that
much more readable (to most of us, I imagine). :)

I tend to prefer the unified diff output format as well,
which is now engrained in many folks because it is what git
diff uses, e.g.:

diff -u ssl.conf.sav ssl.conf

In the end, I think you could use:

$ cat <<-EOF | sudo tee /etc/httpd/conf.d/00-setzco.dyndns.org.conf >/dev/null
<VirtualHost _default_:443>
    DocumentRoot "/var/www/html"
    ServerName setzco.dyndns.org:443
    SSLCertificateFile /etc/letsencrypt/live/setzco.dyndns.org/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/setzco.dyndns.org/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/setzco.dyndns.org/chain.pem
</VirtualHost>
EOF

(That's not tested with httpd, so I may be missing
something.  You can run `sudo httpd -t` or `sudo apachectl
configtest` to check for issues.)

And then you don't have to wonder whether future changes to
/etc/httpd/conf.d/ssl.conf need to be merged into your
modified config file.

It's not a huge problem, but there are good reasons that
Let's Encrypt doesn't (or shouldn't) recommend you modify
the packaged files.

As with most rules or guidelines, if you know the reason for
them and why they don't apply to your situation, you're free
to ignore them. :)

[Jeffrey Walton]

On Thu, May 29, 2025 at 6:08 PM Todd Zullinger  wrote:
> Barry wrote:
> > > On 29 May 2025, at 16:38, Michael D. Setzer II via users  wrote:
> > >
> > > No need to setup a Virtual Host. Don't know why they don't list this
> > > option.
> >
> > My guess is because almost everyone uses VirtualHost sections.
>
> And chage the file there means you now have to track future
> changes to it yourself rather than picking them up via the
> normal package updates.
>
> It's simply not the right way to make such changes.  It's
> your system, so you're free to do it however you want, but
> it's a good thing that Let's Encrypt doesn't recommend that
> course of action.

Also see https://docs.fedoraproject.org/en-US/fedora-server/services/httpd-basic-setup/
and the section, "Configure a Virtual Host for the domain".

Jeff

[Tim]

On Thu, 2025-05-29 at 20:05 -0400, Jeffrey Walton wrote:
> Also see https://docs.fedoraproject.org/en-US/fedora-server/services/httpd-basic-setup/
> and the section, "Configure a Virtual Host for the domain".

When following such instructions, you have to be careful about the
choice of where you put virtually hosted sites.  If you do decide to
make sub-directories inside /var/www/html (as some advocate, and is
mentioned in that linked page) you have to make sure that nobody
connecting to the IP of the server can simply append the filepath used
by the site to the IP address, and bypass any security restrictions.

My advice is never do it.  *Always* do virtual hosts outside of
/var/www/html.  Hackers will try to find things, make it impossible for
them.

My public server's logs has long lists of hacking attempts that will
fail because what they're looking for doesn't exist.  But obviously it
does exist for other webservers.  Years ago it was commonly FrontPage
weaknesses they targeted, recently it's WordPress.  Neither of which I
use.  Just about all of those content management systems have flaws,
and you need to keep on top of updates on a daily matter.  And people
install them and configure them in dumb ways too (such us making
everything world readable and writeable).

[Michael D. Setzer II]

On 30 May 2025 at 19:49, Tim via users wrote:

Subject:        	Re: How to setup certs for https access for Fedora 
42?
To:             	[e-mail], Community support for 
Fedora users
    
Date sent:      	Fri, 30 May 2025 19:49:29 +0930
Send reply to:  	Community support for Fedora users 

From:           	Tim via users 
Copies to:      	Tim
> On Thu, 2025-05-29 at 20:05 -0400, Jeffrey Walton wrote:
> > Also see https://docs.fedoraproject.org/en-US/fedora-server/services/httpd-basic-setup/
> > and the section, "Configure a Virtual Host for the domain".
>
> When following such instructions, you have to be careful about the
> choice of where you put virtually hosted sites.  If you do decide to
> make sub-directories inside /var/www/html (as some advocate, and is
> mentioned in that linked page) you have to make sure that nobody
> connecting to the IP of the server can simply append the filepath used
> by the site to the IP address, and bypass any security restrictions.

First thanks for the info. Don't have anything critical on system. 
Just the /var/www/html with about 8 simple web pages. Map ports 
80 and 443 to that machine. So, just provides links to info from the 
Public data of my old College Staffing Pattern and the sister 
Univercity down street. Both put the data in PDF files that are hard 
to get data from. Pull data via pdf2txt and put it into Mariadb that 
is like to web pages for sorting. Also, do similar to staffing pattern 
info they update every 3 months. Been doing it going back to 2004. 
https://setzco.dyndns.org/GCCHTML.html is primary page. Did just 
tweak it to push http to https. So, seems to work fine. Seen some 
browsers do that on own, and some even force to https. Mostly 
spreadsheet links and simple php to the mariadb databases. So, no 
other data. Notice your noreply address ended with an au. I'm from 
Guam (close to au). Currently, in NV. Mom just passed away. last 
year.
> My advice is never do it.  *Always* do virtual hosts outside of
> /var/www/html.  Hackers will try to find things, make it impossible for
> them.

Agree. Had hackers always probing the College public IPs. Had 4 
servers in my building with public IPs, but then 8 computer labs 
with private networks behind them each lab with own network.
> My public server's logs has long lists of hacking attempts that will
> fail because what they're looking for doesn't exist.  But obviously it
> does exist for other webservers.  Years ago it was commonly FrontPage
> weaknesses they targeted, recently it's WordPress.  Neither of which I
> use.  Just about all of those content management systems have flaws,
> and you need to keep on top of updates on a daily matter.  And people
> install them and configure them in dumb ways too (such us making
> everything world readable and writeable).

Thanks again. Just do it more out of habit. Use to be vice chare of 
union, so found the data in a usuable format interesting.

Have a great day.
> --
>
> uname -rsvp
> Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64
> (yes, this is the output from uname for this PC when I posted)
>
> Boilerplate:  All unexpected mail to my mailbox is automatically deleted.
> I will only get to see the messages that are posted to the mailing list.
>
> -- 
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor (Retired)     
 mailto:[e-mail]                            
 mailto:[e-mail]
 mailto:[e-mail]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[Samuel Sieb]

On 5/30/25 3:19 AM, Tim via users wrote:
> On Thu, 2025-05-29 at 20:05 -0400, Jeffrey Walton wrote:
> > Also see https://docs.fedoraproject.org/en-US/fedora-server/services/httpd-basic-setup/
> > and the section, "Configure a Virtual Host for the domain".
>
> When following such instructions, you have to be careful about the
> choice of where you put virtually hosted sites.  If you do decide to
> make sub-directories inside /var/www/html (as some advocate, and is
> mentioned in that linked page) you have to make sure that nobody
> connecting to the IP of the server can simply append the filepath used
> by the site to the IP address, and bypass any security restrictions.

That page doesn't suggest using /var/www/html.  It suggests 
/var/www/<sitename>, but recommends using /srv.  I've always used 
directories under /var/www because it's a lot easier and doesn't require 
any selinux modifications.

[Patrick O'Callaghan]

On Fri, 2025-05-30 at 17:11 -0700, Samuel Sieb wrote:
> On 5/30/25 3:19 AM, Tim via users wrote:
> > On Thu, 2025-05-29 at 20:05 -0400, Jeffrey Walton wrote:
> > > Also see https://docs.fedoraproject.org/en-US/fedora-server/services/httpd-basic-setup/
> > > and the section, "Configure a Virtual Host for the domain".
> >
> > When following such instructions, you have to be careful about the
> > choice of where you put virtually hosted sites.  If you do decide to
> > make sub-directories inside /var/www/html (as some advocate, and is
> > mentioned in that linked page) you have to make sure that nobody
> > connecting to the IP of the server can simply append the filepath used
> > by the site to the IP address, and bypass any security restrictions.
>
> That page doesn't suggest using /var/www/html.  It suggests 
> /var/www/<sitename>, but recommends using /srv.  I've always used 
> directories under /var/www because it's a lot easier and doesn't require 
> any selinux modifications.

I wanted to have a large Calibre database under /var/www but on a
separate drive with a symlink. I was constantly impeded by SElinux
until I used a bind mount, which solved the problem (I know semanage
and restorecon would also work).

poc

[Todd Zullinger]

Patrick O'Callaghan wrote:
> On Fri, 2025-05-30 at 17:11 -0700, Samuel Sieb wrote:
> > On 5/30/25 3:19 AM, Tim via users wrote:
> > > On Thu, 2025-05-29 at 20:05 -0400, Jeffrey Walton wrote:
> > > > Also see https://docs.fedoraproject.org/en-US/fedora-server/services/httpd-basic-setup/
> > > > and the section, "Configure a Virtual Host for the domain".
> > >
> > > When following such instructions, you have to be careful about the
> > > choice of where you put virtually hosted sites.  If you do decide to
> > > make sub-directories inside /var/www/html (as some advocate, and is
> > > mentioned in that linked page) you have to make sure that nobody
> > > connecting to the IP of the server can simply append the filepath used
> > > by the site to the IP address, and bypass any security restrictions.
> >
> > That page doesn't suggest using /var/www/html.  It suggests 
> > /var/www/<sitename>, but recommends using /srv.  I've always used 
> > directories under /var/www because it's a lot easier and doesn't require 
> > any selinux modifications.
>
> I wanted to have a large Calibre database under /var/www but on a
> separate drive with a symlink. I was constantly impeded by SElinux
> until I used a bind mount, which solved the problem (I know semanage
> and restorecon would also work).

To expand on that for the benefit of others who may not know
how to use semange and restorecon in a case like this, the
*_selinux man pages often contain useful information.  In
this case, that is in httpd_selinux(8).

It is relatively long, but in the FILE CONTEXTS section it
mentions how to configure things if you want httpd to serve
files from an alternate location:

httpd policy stores data with multiple different file context
    types under the /var/www directory.  If you would like to store
    the data in a different directory you can use the semanage
    command to create an equivalence mapping.  If you wanted to store
    this data under the /srv directory you would execute the
    following command:

semanage fcontext -a -e /var/www /srv/www
    restorecon -R -v /srv/www

The *_selinux man pages for services which are part of
selinux-policy are provided by selinux-policy-doc.