azure

Mastering URL Allow Lists in Microsoft Edge

/ Konkretor / Leave a comment

URL allow lists are a crucial part of managing web access in enterprise environments, but they can be tricky to configure correctly, especially when it comes to handling subdomains in Microsoft Edge via Intune. Let’s dive into a common issue that many IT administrators face and its surprisingly simple solution.

The Challenge

Imagine you’re managing a corporate environment where you need to allow access to multiple subdomains. For example:

  • app1.contoso.com
  • app2.contoso.com
  • app3.contoso.com
  • portal.contoso.com

The Common Mistake

Most administrators’ first instinct is to use wildcards, resulting in something like:

*.contoso.com

This seems logical, but if you’ve tried this in Edge’s URL Allow List policy, you’ve probably found that it doesn’t work as expected. Your websites remain blocked, and you’re left wondering what went wrong.

The Solution

Here’s the surprising part: the solution is simpler than you might think. Instead of using wildcards, you just need to list the base domain:

contoso.com

This single entry automatically allows:

  • The base domain (contoso.com)
  • All subdomains (www.contoso.com, app.contoso.com)
  • Even nested subdomains (test.app.contoso.com)

The Dot Prefix: Exact Matching

Sometimes you want to match only a specific domain without including its subdomains. For this, add a dot prefix:

.portal.example.com

This matches only that exact domain, not its subdomains.

Practical Configuration Examples

Here’s how to structure your allow list properly:

# Allow all subdomains
example.com
contoso.com

# Exact matches only
.portal.example.net
.login.contoso.com

# IP addresses (wildcards still work here)
172.16.*
192.168.*

Best Practices

  1. Avoid using wildcards (*) for domains
  2. Use the base domain to allow all subdomains
  3. Add a dot prefix for exact domain matches
  4. Keep IP address wildcards as they are
  5. Document your URL patterns for future reference

Important Notes

  • IP addresses are the only place where wildcards still work as expected
  • The dot prefix method is particularly useful for specific service endpoints
  • This behavior is specific to Edge’s URL Allow List policy in Intune

Final Thoughts

Understanding how Edge’s URL filtering works can save you hours of troubleshooting and configuration time. Sometimes the simplest solution is the most effective one – in this case, less really is more.

Have you encountered similar issues with URL allow lists? How did you handle them? Share your experiences in the comments below!

How to Fix pip SSL Certificate Verification Errors in Python

/ Konkretor / Leave a comment

Having trouble installing Python packages with pip? Getting that frustrating SSL certificate verification error? You’re not alone. In this post, I’ll explain what’s causing this common issue and show you how to fix it quickly and securely.

The Problem

When trying to install Python packages using pip, you might encounter this error:

SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] 
certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)'))

This error occurs when pip cannot verify the SSL certificate of PyPI (Python Package Index) servers. It’s a security feature meant to protect you from potential man-in-the-middle attacks, but it can be frustrating when you’re just trying to install packages.

Understanding the Cause

This issue typically happens because:

  1. Your system’s SSL certificates are not up to date
  2. The SSL certificates are missing entirely
  3. Your system can’t locate the certificate store

The Solution

There are several ways to resolve this issue. I’ll present them in order of recommended approach:

1. Install System Certificates (Recommended)

The most secure and recommended solution is to install the system certificates:

pip install pip-system-certs

This package ensures pip uses your system’s certificate store, which is typically more secure and up-to-date.

2. Configure Trusted Hosts

If the above solution doesn’t work, you can explicitly tell pip to trust PyPI’s hosts:

pip config --global set global.trusted-host "pypi.org files.pythonhosted.org"

Or use it directly in your pip install command:

pip install --trusted-host pypi.org --trusted-host files.pythonhosted.org <package-name>

3. Update Your Certificates

On some systems, you might need to update your certificate store:

  • Windows: Update Windows and Python to the latest version
  • macOS: Run the “Install Certificates.command” in your Python folder
  • Linux: Update ca-certificates package:
  sudo apt-get update
  sudo apt-get install ca-certificates

Best Practices and Security Considerations

While the trusted-host approach works, it’s important to understand that it bypasses SSL verification. This should only be used in controlled environments where you’re certain about the security of your network.

Always prefer using proper SSL certificates when possible, as they provide:

  • Protection against man-in-the-middle attacks
  • Verification of package source authenticity
  • Secure encrypted communication

Alternative Solutions

If you’re working in a corporate environment, you might also:

  1. Configure pip to use your corporate proxy
  2. Set up a local PyPI mirror
  3. Use a custom certificate authority

Conclusion

SSL certificate errors can be frustrating, but they exist for a good reason – your security. The recommended approach is to install system certificates using pip-system-certs. If that doesn’t work, configuring trusted hosts is a quick fix, but remember to consider the security implications.

Remember: Security features like SSL verification are there to protect you and your code. While it might be tempting to disable them, it’s always better to fix the underlying certificate issues properly.

Have you encountered other pip-related issues? Let me know in the comments below!

jenkins you have requested strict checking ssh git server issue

/ Konkretor / Leave a comment

Jenkins sometimes a little bit strange but it works at is.

you have addes a new ssh key and you got following error “you have requested strict checking”

Under configuration “Global Security” scroll down and choose what you need

look a the screen snipet, this config works well.

https://docs.cloudbees.com/docs/cloudbees-ci-kb/latest/client-and-managed-masters/host-key-verification-for-ssh-agents

https://issues.jenkins.io/browse/JENKINS-43062