For the last 3 years we used Let's Encrypt certificates for our user group site. Since there is no direct and easy-to-use solution in Azure, we needed the sjkp plug-in. Unfortunately, that no longer works after we moved from Windows to Linux as the hosting platform and we needed to fall back to a manual process for the renewal of the certificates.
Since a few people had troubles with creating the .well-known folder for the security.txt in ASP.Net, I will explain in this post how you can do it in .Net 4.8 and .Net 6.
Your web application is under the constant thread of hackers. It does not matter if you have a small pet project application on the internet or a big commercial site. As soon as it is accessible from the internet, someone will attack it.
Sometimes we get lucky, and someone finds a security issue and wants to report it. But where should they report it to? The address [email protected] may be processed by someone without any knowledge of IT or security and ignores the report.
If you need to block an IP address, you can do that directly in IIS 10 with the Web IP Security feature. You can install it with this PowerShell command (run it as administrator):
ASP.NET Core Identity offers you a little interface called IEmailSender to wire up your own logic to send emails for account confirmation and password recovery. The official tutorial at Microsoft uses SendGrid for those emails. While this service has certainly its place, we do not want to change our email infrastructure just because we only can find tutorials for SendGrid.
After deleting the developer certificate in IIS Express I could recreate a new one as described in this post. This approach worked, even when I needed to run the IisExpressAdminCmd for every port I use. At least, that was how I could fix all problems with SSL and IIS Express on my machine until a few weeks ago. I finally gave up as I got this error:
Error code: SSL_ERROR_RX_RECORD_TOO_LONG
Personal Access Tokens (PAT) for Azure DevOps have an expiration date. They can be valid for a year at most. If this expiration date comes closer, Azure DevOps sends you an email with this subject:
Azure DevOps personal access token nearing expiration
Creating a client-side SSL certificate that you can use to log in on a web site is a challenge. Every part from your certificate to the settings in your web application must work together or you only get an error message. You may have created SSL server certificates without any problems, but believe me, client certificates are another beast.
As explained in my earlier post, Visual Studio creates a self-signed certificate for your web application that allows you to access your site over HTTPS. If you accidentally remove this certificate, your web application will fail to load and report something like ERR_CONNECTION_RESET on the default error page of your browser:
When we tried our first attempt to disable unsecure protocols, we run into an annoying problem on the servers that run SQL Server. After disabling all the outdated security protocols, we could no longer connect to our databases. The error message was no help at all:
