.at domain and SSL certificate: set up HTTPS correctly

1. Registration, DNS and a certificate do different jobs

Buying a .at domain secures registration of the name. DNS records direct requests towards the services you choose. HTTPS protects the connection to a website using TLS; the certificate is part of the setup of the web service visitors actually reach. People still commonly call this an “SSL certificate”. A working DNS record therefore does not prove that HTTPS is ready. Start by recording where you manage the domain, which service provides the website and where the active DNS records are maintained. Those three answers help you find the relevant settings instead of changing several unrelated things at once.

2. Add the domain to your website service first

Open the custom-domain settings at your website service and add the address you want to use. Then enter only the DNS destinations that service specifies. An A record takes an IPv4 address; a CNAME takes a destination hostname, not a complete URL containing https:// and a page path. Include the www version if you intend to use it. Leave existing MX and email-related TXT records in place. Needing a certificate is not, by itself, a reason to replace your nameservers. Before changing anything else, establish which DNS management service is active. Editing an unused zone will not fix the connection.

3. Match the certificate to the actual website address

The root domain and its www version are different hostnames. If visitors should be able to reach both, each HTTPS endpoint must present a certificate valid for that address. Check the covered names in the browser’s certificate information or your website service’s settings. A certificate for a subdomain does not automatically cover the root domain. A wildcard certificate is not permission to cover every possible naming level either: the usual wildcard matching described in RFC 9525 covers exactly one additional label. For an initial setup, a clear list of the hostnames you really need is usually more useful than choosing the most complicated certificate arrangement.

4. Follow the current domain-validation instructions

Certificate issuance requires proof of control over the name. Your website service may automate this or ask you to publish a DNS record. ACME describes HTTP and DNS validation methods, among others; DNS-01 uses a supplied TXT value under an _acme-challenge name. Copy the exact hostname and value from your current request. Do not invent a demonstration value or overwrite an unrelated verification record. Ask the service managing the certificate whether a record may be removed after validation or must remain for future renewals. Keep that instruction with the setup notes so a later tidy-up does not accidentally break certificate renewal.

5. Identify the error instead of simply waiting

Record the complete address you opened, the error message and the time. Check that same address on another device or network without bypassing any security warning. If only one address version fails, compare its DNS destination and certificate coverage. An older DNS cache can still send visitors to a previous server; however, an incorrectly issued certificate on the intended server does not become correct just by waiting an arbitrary amount of time. Precise observations are more useful to support than several settings changed simultaneously. Do not send passwords, private keys or confidential certificate files when describing the problem.

6. Configure redirects after HTTPS works

Once both address versions open securely, configure the redirect to your preferred main address at the web service. With an HTTPS request, the secure connection is established before an HTTP redirect response is returned. The redirecting HTTPS address therefore needs an appropriate certificate as well. Test the root domain and www with both http:// and https://. Include an actual subpage so a redirect does not accidentally send every visitor to the homepage. A DNS change alone does not create a web redirect. DNSSEC is a separate technology again; do not disable it as a supposed repair for a TLS certificate error.

7. Plan certificate renewal and domain renewal separately

Your domain’s registration period and your website certificate’s validity are separate matters. Renewing a domain does not renew a badly managed certificate, and issuing a new certificate does not extend domain registration. Establish whether your website service renews certificates automatically and how you will hear about a failure. Recheck the hostnames after moving hosting. Before publishing a new address, try the important entry points on a phone. HTTPS does not establish that a website’s content or business is trustworthy. It also does not replace secure account access, site maintenance or a clear record of who handles problems.

• Open the root domain and www without browser warnings.
• Check a real subpage and the redirect destination.
• Record who handles certificate errors and renewal.
• Track the domain renewal deadline in your account as a separate task.

8. Budget for the domain and website separately

A standard new .at domain at atdomain.at costs €12.99 total for the first year, with renewal currently €15.99 total per additional year. Assuming unchanged prices, three years cost €44.97 total for the domain. Website hosting, mailboxes and additional certificate services are not included. Ask the website service you choose which HTTPS features its plan provides and who maintains them. You can connect your domain to a suitable existing service without moving several services at the same time. Before buying, check the availability of your preferred name; afterwards, treat connecting the website and testing HTTPS as separate setup steps. For a new .at domain, you can instead choose the 3-year plan for €39.00 total: registration and two annual renewals are included, with no further payment during the plan term. Save €5.97 against €44.97 with annual payments at today’s prices. Afterwards, renewal is offered at the annual price then in effect. No automatic card charge.