# Additional Reasons for Issuing Certificates to IP Addresses **URL:** \ **Category:** Feature Requests\ **Created:** [May 15, 2024, 9:49am UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433 "2024-05-15T09:49:30Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Amidst](https://avatars.discourse-cdn.com/v4/letter/a/46a35a/32.png) [@Amidst](https://community.letsencrypt.org/u/Amidst)\ **Post date:** [May 15, 2024, 9:49am UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/1 "2024-05-15T09:49:30Z")
I have noticed several discussions over the past three years about whether it is necessary, feasible, or appropriate to issue SSL certificates for IP addresses. In fact, I have a similar need. Therefore, I would like to provide some additional reasons that have not been fully discussed yet. As far as I know, currently only ZeroSSL can issue free certificates for IP addresses, but each issuance is only for three months, and each account can only issue three times, which is quite inconvenient. Of course, it is acceptable, and this is the method I am currently using. In general, this is a rare demand because using domain names is usually cheap and convenient. Therefore, I fully understand the delay in related plans. However, in mainland China, there are very strict regulations on the management of websites/domains. Any domain name resolved to a server in mainland China must be registered and approved by the relevant government authorities, otherwise the resolution will be blocked. This registration process is very cumbersome, requiring written identification materials, guarantees, expected website plans, etc., and individuals are not allowed to set up some common websites (such as blogs) without written permission (which is almost impossible to obtain). Cloud service providers and regulatory authorities also conduct regular checks on the content of registered domain names to ensure it complies with the initially approved content, so you cannot easily change the website content. Of course, this also means that you cannot easily change domain names, and some domain suffixes (such as some free or cheap suffixes) are not included in the list of registrable domain suffixes published by the government. This increases the cost of obtaining domain names. Other alternatives that do not use domain names (such as DDNS) are also subject to the same degree of regulation. By the end of 2023, there were nearly 1.3 billion internet users in China. I believe many of these 1.3 billion people, who try to set up small websites/services on cloud servers to provide convenience for themselves, their families, and friends, are troubled by the difficulty of obtaining domain names. However, they still need SSL certificates for HTTPS secure communication. After all, in 2024, using HTTP communication is indeed too unsafe. In summary, I believe this is a long-ignored situation/need that has not been mentioned here. Therefore, I am posting this in the hope that someone will see it and bring about some discussion. Of course, this is a demand caused by strict regulations from the internet authorities of specific countries, and no one is obligated to pay for their mistakes. I am not asking you to introduce features for such special needs or to increase the workload, possibly bringing additional risks to public services. But it does cause inconvenience for many people, and many internet activities are forced to be exposed to risks. I just hope that the next time you consider whether to implement this feature, you take into account what I have mentioned here. ---
**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\ **Post date:** [May 15, 2024, 9:58am UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/2 "2024-05-15T09:58:56Z")
> > > This bug is an umbrella/tracking bug, acting as a one-stop-shop to see progress …on the multiple sub-tasks necessary to achieve this 2024 OKR. > > We intend to support IP Address identifiers only in short-lived certificates. > > Prerequisities: > \- \[\] https://github.com/letsencrypt/boulder/issues/7309 > \- \[\] https://github.com/letsencrypt/boulder/issues/7310 > > Subtasks: > \- \[\] Teach the SA to store authorization objects with identifier type "ipAddress" > \- \[\] Teach the RA to plumb new-order ipAddress identifiers to the SA > \- \[\] https://github.com/letsencrypt/boulder/issues/2706 in the VA and RVA > \- \[\] Teach the RA to plumb challenge ipAddress identifiers to the VA and RVA > \- \[\] Ensure the CA produces correct and compliant certificates including IP addresses > \- \[\] Ensure the CA rejects issuance of long-lived certs with ipAddress identifiers > \- \[\] Teach the RA to plumb finalize ipAddress identifiers to the CA > \- \[\] Teach the WFE to plumb ipAddress identifiers to the RA > \- \[\] Optional: Restrict ipAddress identifiers to an allow-list of registration IDs, to allow slow controlled roll-out slowly building ---
**Author:** ![Amidst](https://avatars.discourse-cdn.com/v4/letter/a/46a35a/32.png) [@Amidst](https://community.letsencrypt.org/u/Amidst)\ **Post date:** [May 15, 2024, 10:05am UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/4 "2024-05-15T10:05:37Z")
Thanks.This is very exciting. I didn't notice this before. I just saw a related post in the community from January this year, but it has been closed and can't be replied to, so I decided to start a new one. ---
**Author:** ![catharsis](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/catharsis/32/48964_2.png) [@catharsis](https://community.letsencrypt.org/u/catharsis)\ **Post date:** [May 16, 2024, 1:16am UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/5 "2024-05-16T01:16:49Z")
Exciting to see that this is being worked on. Has it been decided what the maximum duration of IP certificates will be? ---
**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\ **Post date:** [May 16, 2024, 1:41am UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/6 "2024-05-16T01:41:27Z")
10/7 days, because it's planned to only allow IP san on short lifetime ones ---
**Author:** ![mcpherrinm](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mcpherrinm/32/59604_2.png) [@mcpherrinm](https://community.letsencrypt.org/u/mcpherrinm)\ **Post date:** [May 16, 2024, 3:59am UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/7 "2024-05-16T03:59:18Z")
Likely something slightly less than 7 days, maybe 150 or 160 hours. We aren’t launching IP certs until after short-lived certs, which we aren’t launching until at least we horizontally shard our database and add support for certificate profiles, both of which are big multi-month projects. So there’s a number of blockers to resolve, and thus no timeline commitment yet. ---
**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\ **Post date:** [May 16, 2024, 4:56am UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/8 "2024-05-16T04:56:19Z")
If I trust github issue about certificate profile it is almost done except webpage document and actually having non-default profile: not sure what to write on Ford catalog when only thing sell is black Ford T > > > This bug is an umbrella/tracking bug, acting as a one-stop-shop to see progress …on the multiple sub-tasks necessary to achieve this 2024 OKR. > > The design we have landed on is > 1) the CA (and the WFE?) will be configured with multiple profiles, each of which has a human-readable name (and maybe a guaranteed-unique ID). > 2) the client will specify the profile they want as a query parameter on their directory URL -- this means profile selection only requires users to update their directory url, and doesn't require client software itself to be updated -- and the parameter will be reflected back in the directory object so it gets used in the new-order request as well. > 3) the SA will store the requested profile on the Order object so it can be used at finalization time > > Subtasks: > \- \[x\] #6966 > \- \[x\] #7324 > \- \[x\] The RA can plumb a requested new-order profile to the SA > \- \[x\] #7366 > \- \[x\] #7332 > \- \[\] #7392 > \- \[\] Public announcements and documentation regarding how a client can request a profile ---
**Author:** ![Patryk](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/patryk/32/8485_2.png) [@Patryk](https://community.letsencrypt.org/u/Patryk)\ **Post date:** [May 16, 2024, 2:33pm UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/9 "2024-05-16T14:33:20Z")
Google Trust Services might be able to issue certificates to IP addresses, according to their [FAQ.](https://pki.goog/faq/#faq-IPCerts) ---
**Author:** ![aarongable](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/aarongable/32/42043_2.png) [@aarongable](https://community.letsencrypt.org/u/aarongable)\ **Post date:** [May 16, 2024, 3:26pm UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/10 "2024-05-16T15:26:26Z")
Yep, technical support for multi-profile issuance is basically complete. We're not talking about it publicly until after June 6, to avoid adding any confusion to the changes happening on that date. Support for profile selection will require client-side changes, so there will be outreach to describe how clients can implement it, and encouragement for website operators to update their clients. Support for short-lived certs requires a couple pieces beyond that, largely around ensuring our infrastructure can support the increased issuance volume, and perhaps implementation of an allow-list to ensure that issuance volume doesn't grow too quickly. Then support for IP Address certs requires quite a bit more work, to ensure we are fully compliant when conducting validation of IP addresses and when formatting IP addresses in certificates. We have internal goals/timelines for when we'll issue our first IP address certificate, but we're not committing to those in public yet. ---
**Author:** ![Amidst](https://avatars.discourse-cdn.com/v4/letter/a/46a35a/32.png) [@Amidst](https://community.letsencrypt.org/u/Amidst)\ **Post date:** [May 16, 2024, 3:56pm UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/11 "2024-05-16T15:56:18Z")
Hello, thank you for your response. I have reviewed more specific documents, and it turns out that Google Trust Services can indeed issue certificates containing IP addresses. However, this is currently limited to customers who control an IANA assigned IP address block. So, for general users, this doesn't seem feasible. Moreover, as far as I know, due to internet restrictions, servers in mainland China cannot directly connect to Google's ACME API services. [Relevant Google cloud blog](https://cloud.google.com/blog/products/identity-security/automate-public-certificate-lifecycle-management-via--acme-client-api) ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [May 16, 2024, 4:15pm UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/12 "2024-05-16T16:15:27Z")
@aarongable Will you include IPv6 support when IP adddress certs will become available? ---
**Author:** ![mcpherrinm](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mcpherrinm/32/59604_2.png) [@mcpherrinm](https://community.letsencrypt.org/u/mcpherrinm)\ **Post date:** [May 16, 2024, 4:20pm UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/13 "2024-05-16T16:20:24Z")
Yes, I don’t expect any difference between v4 and v6, beyond some rate limit details probably. ---
**Author:** ![catharsis](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/catharsis/32/48964_2.png) [@catharsis](https://community.letsencrypt.org/u/catharsis)\ **Post date:** [May 16, 2024, 11:10pm UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/14 "2024-05-16T23:10:46Z")
> [@Amidst](#): > > Google Trust Services can indeed issue certificates containing IP addresses. However, this is currently limited to customers who control an IANA assigned IP address block Oops, I didn't read the 2nd half of that carefully enough & wasted 4 hours playing around with Google's CA, oh well. Learning experience. I did discover something interesting though... It appears that certbot still displays the same "The Let's Encrypt certificate authority will not issue certificates for a bare IP address." **even when you're requesting from another CA**? Seems like no attempt is made to contact the CA's server so I guess the message is hard-coded into certbot? checked Github and it seems to be in util.py, doesn't seem to check which CA is actually being used so the message will always say "Let's Encrypt" ---
**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\ **Post date:** [May 16, 2024, 11:32pm UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/15 "2024-05-16T23:32:51Z")
Certbot also always directs people to _this_ forum for help with failures, regardless of which CA they're using. (I don't personally particularly _object_ to this forum being the de-facto Certbot support forum for all CAs, but it does seem a little weird how it presumes that people here would be able to help regardless.) ---
**Author:** ![catharsis](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/catharsis/32/48964_2.png) [@catharsis](https://community.letsencrypt.org/u/catharsis)\ **Post date:** [May 16, 2024, 11:39pm UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/16 "2024-05-16T23:39:52Z")
The link to the forum is sensible however the explicit reference " **The Let's Encrypt certificate authority** will not issue certificates for a bare IP address" seems inappropriate when using a different Certificate Authority to which the statement about bare IP addresses might or might not actually apply. ---
**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\ **Post date:** [May 16, 2024, 11:40pm UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/17 "2024-05-16T23:40:45Z")
Oh yes, wasn't trying to disagree with you in the slightest. Just saying that there are multiple places where certbot still seems to assume that Let's Encrypt is the entire ACME world. 🙂 ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [June 15, 2024, 11:41pm UTC](https://community.letsencrypt.org/t/additional-reasons-for-issuing-certificates-to-ip-addresses/218433/18 "2024-06-15T23:41:08Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.